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] 4 5 ... 34
31
Vývoj / Re:MySQL a přecenění se změnou DPH
« kdy: 01. 01. 2024, 22:11:29 »
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.

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

33
Vývoj / Re:MySQL a přecenění se změnou DPH
« kdy: 01. 01. 2024, 20:03:19 »
Ježiš, to jsem čekal, že se objeví nějaký chytrák, co se chytí vyjímek, jako přenesená DPH, zahraničí apod. a další ...
Vas zrejme podrazdila ta moja narazka na potreby bezcennych vekslakov... Darmo tu prskate, tento boj by ste si mal vyriesit vo svojej mysli.


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.

34
Vývoj / Re:MySQL a přecenění se změnou DPH
« kdy: 01. 01. 2024, 13:53:32 »
....
Alebo len vy ste necital celu diskusiu, pripadne len ciastocne, lebo pre tak dlhy text neudrzite kontext?

Rozporujete moje tvrdenie ze je len cena (zaklad DPH + DPH), zalkad DPH a sadzba DPH, tym ze tvrdite ze dva subjekty si fakturuju ceny, ktore su suctom zakladu DPH a DPH? 😁

35
Vývoj / Re:MySQL a přecenění se změnou DPH
« kdy: 31. 12. 2023, 21:34:42 »
LOL, kdyz to rika frikulin z internetu, tak to tak musi byt, co? :D

Ad frikulin z internetu... Pri par certifikaciach som uz bol, ci uz ako vyvojar alebo ako temleader...

Ad halierove dorovnanie... Ak si nejaky bezcenny vekslak mysli ze cena je zaklad DPH, a ze samotna DPH je naklad koncoveho zakaznika, tak je to len jeho problem. Potom nie je divu ze sa snazi dorovnat zaklad DPH na nejake pekne cislo. Ako som uz pisal, neexistuje cena s DPH a cena bez DPH. Je len cena, zaklad DPH a sadzba DPH.

36
Vývoj / Re:MySQL a přecenění se změnou DPH
« kdy: 31. 12. 2023, 14:32:26 »
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).
Na danovom doklade mate aj medzivysledky, minimalne suhrn dph sadzieb. Ak ma system atributy pokladnicneho systemu (vydava danove doklady) tak by mal mat certifikaciu od danoveho uradu. Danovak, ktory ten system bude auditovat sa vam na nejake spekulativne uvahy vykasle. Pouzije svoju blbu ekonomicku kalkulacku, ktora zaokruhluje na 2 desatinne miesta (cele centy/haliere) a prepocita ten danovy doklad. Ak mu to nebude sediet na cent, tak vam to hodi na hlavu. A nie, halierove vyrovnanie nie je stahdartny postup, v mnohych krajinach EU sa nepouziva.

37
Vývoj / Re:MySQL a přecenění se změnou DPH
« kdy: 31. 12. 2023, 14:19:58 »
To by platilo, pokud uvazujete ciste o B2C eshopu a nejste platce

Z pohladu uctovnictva ziadna cena bez DPH a s DPH neexistuje. Mate Cenu, Sadzbu DPH a Zaklad DPH. To co vacsinu ludi pletie je ze pri B2B mate nulovu sadzbu a pri nulovej sadzbe je cena == zaklad.

38
Vývoj / Re:MySQL a přecenění se změnou DPH
« kdy: 30. 12. 2023, 19:44:33 »
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...

39
Server / Re:Přegenerování stávajícího SSH klíče?
« kdy: 28. 12. 2023, 04:46:23 »
Ahoj,
hledal jsem na internetu a divím se, že jsem k tomuto tématu nic nenašel, tak se ptám tady.
Dá se nějak přegenerovat stávající klíč, který je 1024bitový na nový 4096bitový? Jde mi o to, že můj klíč už dávno není bezpečný, ale stále ho používám, protože ho mám na desítkách serverů a to i v AWS, kde přidání nového klíče je ještě složitější.
Ideálně tedy přegenerovat tak, že bude kompatibilní se stávajícími public klíči. Dá se to?
Díky.

Nenasiel, pretoze to zrejme ani nikoho nenapadlo ist na to takto. Idealny sposob ako na to je napisat si task pre ansible, ktory kluc na server doplni, pripadne vymeni. Tento task ansible spusti pre kazdy ciel, ktory ma subore hosts. Ak neviete kde vsade chcete kluc zmenit, tak je nad vymenou zbytocne uvazovat, pretoze bez hostname sa na ten server ani neprihlasite.

40
Server / Re:Přegenerování stávajícího SSH klíče?
« kdy: 28. 12. 2023, 04:40:49 »
A nevyzaduje nahodou RSA aby nejvyssi bit modulu byl 1?
Takze navrh na tool c2

Ani tool c2 fungovat nebude. Staci ked sa opat pozriete narovnice pre sifrovanie a desifrovanie. To co zasifrujete modulom o dlzke 1024 bitov, nedokazete desifrovat modulom o dlzke 4096 bitov... Ak neverite, tak si to skuste. V clanku na wiki o RSA ( https://cs.wikipedia.org/wiki/RSA#P%C5%99%C3%ADklad ) mate priklad, kde je pouzity 14 bitovy kluc. Skuste si ho prerobit na 56 bitovy kluc a uvidite ze to bude nefunkcne.

41
Server / Re:Přegenerování stávajícího SSH klíče?
« kdy: 28. 12. 2023, 04:12:40 »
ehm... chapem, ze otazka je to dost nestastna :)... ale ciste teoreticky, co brani doplnit pred cislo v RSA algoritme 3072 nul?

To, ze takyto kluc bude nepouzitelny.

Sifrovanie je z=s^e mod n.
Desifrovanie je s=z^d mod n.
Kde s - sprava, z - zasifrovane, e - verejny exponent, d - sukromny exponent, n - modulus.

To ako je v rovniciach modulus pouzity, urcuje aj to ako ma vyzerat. Najvyssi bit musi byt 1.

42
Vývoj / Re:PostgreSQL: změna dat při logické replikaci
« kdy: 13. 12. 2023, 05:31:52 »
Skoda, bola by to super ficura  :)

Nastastie v postgrese take uchylnosti netreba vymyslat. Mozete pouzit view a definovat mu rules pre non select operacie. Ja osobne to pouzivam skor v pripade ze treba dat do poriadku DB, ale aplikaciu ktora k nej pristupuje a treba ju este nejaky cas udrzat, je nerentabilne upravovat (blackbox alebo spatlanina). Imho, pre vas ucel to bude idealne. Viz https://www.postgresql.org/docs/current/rules.html

43
Studium a uplatnění / Re:ChatGPT a AI pro vývojáře
« kdy: 09. 05. 2023, 12:49:47 »

Pokud se jedna o databaze, tak zde je take jedna skryta zrada - zatimco DECIMAL(x,y) urcuje garantovany ukladani dle x/y parametru, je typ INT(z) fixne dany (32bit) a parametr z rika jen doporuceni na formatovani vystupu :-)
Tak nastastie existuju aj databaze kde si mozete popisat vlastne datovy typy. Napr. postgres. Teda ak by vam nestacil typ money, ktory je interne definovany prave ako 64bit integer. Len sa jeho hodnota deli 100 a tomu je prisposobena aj jeho interna aritmetika. Teda nemusi byt 100, moze to byt 10000 ak mate v locales nastavene indicke rupie, alebo 1000 pre pakistanske rupie...

Co sa tyka decimal, vdaka jeho pomalosti je vhodny akurat na prototypovanie, ak mate moznost definovat vlastne typy a ich internu logiku.

Treba financni reporty z Microsoft store nam chodi ve formatu s 18 desetinnymi misty, tak to holt zatim importuji na DECIMAL(30,18), nez bude jasny co tim chteli jako rict.
Mno, Malejmekej, od nich vela veci funguje divne... Neviem ako to chodi teraz, ale cca v 2010 som robil okolo pokladnicnych systemov. Vtedy nebolo mozne aby sa nejaky financny software neriadil legislativou, nedostali certifikat od danovakov. Siemens sa bol ochotny prisposobit, takze po dlhom vysvetlovani ako to ma fungovat a prikladoch ako to naprogramovat, nakoniec ten certifikat dostali (islo o velkeho zakaznika s prevadzkami po celej europe). Takze ten vas import s 18 desatinnymi miestami by som konzultoval s nejakym uctovnikom ktory dobre rozumie svojej praci. Ak ten financny report je pre vasu internu potrebu tak sa zrejme nic nestane, ale ak na zaklade neho odvadzate dane, tak moze byt problem.

44
Studium a uplatnění / Re:ChatGPT a AI pro vývojáře
« kdy: 09. 05. 2023, 12:15:23 »
Technicky máte pravdu, ale vždy se uvádí, že čísla v plovoucí řádové čárce jsou reprezentací reálných čísel. Protože reprezentace v omezené paměti počítače samozřejmě nedokáže reprezentovat ani libovolné přirozené číslo, reprezentace nekonečných množin je vždy jen přibližná. Takže jako číslo v plovoucí řádové čárce můžete (přibližně) reprezentovat i třeba pí nebo odmocninu ze dvou, což jsou reálná čísla.
V relevantnych zdrojoch sa uvadza ze float umoznuje reprezentovat cisla priblizne. To ze inde sa vacsinou uvadza ako reprezentacia realneho cisla, je velmi zjednodusena interpretacia. Takze floagt su pribliznou reprezentaciou realnych cisel. V danom kontexte je formulacia "priblizne" dolezita a nie je mozne ju vynechat.

Na druhu stranu existuje software ktory dokaze pracovat s pi, odmocninami z 2 alebo 3 a dalsimi iracionalnymi cislami, presne, akurat nepouziva ich ciselnu reprezentaciu ale pozna ich matenatiku a pracuje s nimi formalne

45
Studium a uplatnění / Re:ChatGPT a AI pro vývojáře
« kdy: 09. 05. 2023, 03:25:37 »
A programy, které by pracovaly s celou množinou reálných čísel, jsou velmi vzácné, pokud vůbec takové existují.
Ziaden pocitacovy program nedokaze pracovat s realnymi cislami, vzdy ide o podmnozinu racionalnych cisel. Racioalne cislo je aj float - mantisa aj exponent sa daju vyjadrit zlomkom. Podmnozina koli limitu pamate. Kde to zahaprovalo, ked ste si nie isty, ze take programy vobec existuju? Chybaju znalosti o sposobe ulozenia cisel a o racionalnych cislach, alebo potencial tieto zakladne informacie skombinovat?

Stran: 1 2 [3] 4 5 ... 34