Farid Abdelnour se v příspěvku na blogu rozepsal o novinkám v nejnovější verzi 26.08.0 editoru videa Kdenlive (Wikipedie). Ke stažení také na Flathubu.
Byla vydána nová stabilní verze 8.2 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 152. Přehled novinek i s náhledy v příspěvku na blogu.
Byla vydána nová stabilní verze 4.0 svobodného multiplatformního softwaru pro editování a nahrávání zvukových souborů Audacity (Wikipedie). S rozhraním přepsaným do Qt. Přehled novinek také na YouTube. Ke stažení je oficiální AppImage. Zatím starší verze Audacity lze instalovat také z Flathubu a Snapcraftu.
NVIDIA kupuje Hugging Face za 12,93 miliardy dolarů.
Předobjednat si lze nový jednodeskový počítač Arduino VENTUNO Q s předinstalovaným Ubuntu. S 16 GB LPDDR5 a 64 GB eMMC. Pro lokální LLM, agentní AI, počítačové vidění, robotiku…
Hexpair není nejlepší HEX editor na světě a ani se o to nesnaží. Zato je k dispozici kdykoliv a kdekoliv – všude tam, kde máte svůj Vim. Vznikl jako hobby projekt před pár měsíci a dospěl do stavu, kdy by mohl být užitečný širší komunitě. Přepnout do HEX režimu se dá i uprostřed rozdělané práce: Soubor, který už máte otevřený běžným vim file.md, jedním příkazem přepnete do HEX editoru a dalším příkazem ho můžete vrátit zpět do textu. Kurzor přitom
CERN dlouhodobě používal vlastní sestavení RHEL, ze kterého přešel na CentOS Stream. Federico Vaga a Nikos Tsipinakis ale nyní v přednášce na MiniDebConf Winterthur 2026 popisují plán probíhajícího přechodu na Debian pro řízení akcelerátorů. Důvodem k opuštění CentOS Stream jsou zachování zpětné kompatibility se starším hardwarem, kterou Red Hat narušuje, když tlačí sestavení balíčků pro novější verze architektury (x86-64), a nedostatečné nástroje pro sestavování vlastních balíčků a repozitářů.
UZDoom (Wikipedie), tj. fork GZDoom, byl vydán ve verzi 5.0.0. Videopředstavení na YouTube. Podrobný přehled novinek v Changelogu.
Příručka Linux From Scratch pro sestavení základního linuxového systému byla aktualizována v pravidelném půlročním termínu. Vydání 13.1 shrnuje přes 40 nových verzí balíčků a několik patchů. Navazující příručka Beyond Linux From Scratch s recepty pro sestavení dalších knihoven a aplikací zatím vydána nebyla, ačkoliv vývojová verze stále dostává aktualizace. Lze je číst online nebo stáhnout v HTML či PDF.
Dnešním dnem spouštím novou webovou aplikaci určenou ke generování faktur v otevřených kancelářských formátech OpenDocument (ODF), Microsoft Office Open XML (OOXML) a také XHTML: FAKTURY ON-LINE.
Služba je prozatím pouze ve fázi jednorázového generátoru faktur bez nutnosti přihlášení. Pokud bude dostatečný zájem, budu na aplikaci dále pracovat a nabídnul bych zabezpečenou zónu s kompletní správou fakturačního procesu, možnost vlastních šablon a interoperabilitu s dalšími programy, např. s pomocí REST API.
Pokud narazíte na jakoukoliv chybu -- ať už technickou či právní / ekonomickou (obsah faktury) -- ozvěte se.
Stejně tak se ozvěte, pokud vám faktury budou zlobit v Office či OpenOffice.org a nebo pokud vám půjdou otevřít v programu, který není uvedený ve FAQ.
Tiskni
Sdílej:
PS: SKK jsou slovenský koruny? To ještě funguje?
opraveno.
(UI netreba, len výsledná vygenerovaná faktúra)
), ale aj človek so slobodným povolaním, a taký nemusí mať nevyhnutne IČO a DIČ (aspoň na Slovensku). Podobne DIČ asi nemusia mať zahraničné organizácie.chýba možnosť uhradiť faktúru vzájomným započítaním pohľadávokSpíše chybí možnost tam napsat cokoli vlastního (možností je spousta - kreditem, směnkou, šekem, poštovní poukázkou, dobírkou, postoupením pohledávky, různými kombinacemi atd.).
faktúru nemusí vyplniť len právnická osoba alebo SZČO (po česky: OSVČ ), ale aj človek so slobodným povolaním, a taký nemusí mať nevyhnutne IČO a DIČ (aspoň na Slovensku). Podobne DIČ asi nemusia mať zahraničné organizácie.DIČ by mělo být povinnou položkou u plátců DPH, jinak by se nemělo uvádět vůbec.
Spíše chybí možnost tam napsat cokoli vlastníhoTo by jiz ted melo byt mozne. ICO a DIC jsem udelal obe nepovinne.
chcelo by to lokalizáciu, aby sme to aj my bratia mohli používať (UI netreba, len výsledná vygenerovaná faktúra)To by se casem take mohlo objevit. U OOXML to diky shared strings nebude tezke, u ODF jeste reseni presne nevim, ale tusim, ze neco podobneho tam taky je.
Banka a Bankový účet by nemali byť povinné položky, keďže faktúru možno dať aj splatnú v hotovostiUz nejsou
chýba možnosť uhradiť faktúru vzájomným započítaním pohľadávokTa volba tam pribude, ale nevim teda, jestli v takovem pripade musi mit ta faktura jeste nejakou jinou nalezitost (a ted me taky napada, ze to asi rozhodi format, protoze je to delsi text)
môže byť odberateľ zo zahraničia? (chýbajúce položky v adrese a SWIFT & adresa banky)Zatim nemuze
Pokud jde o ICO, tak nevim jak na Slovensku, ale v pripade CR ziju v predstave, ze kdo nema ICO, nemuze vystavit fakturu... je to tak? (anyone?)
Pokud jde o ICO, tak nevim jak na Slovensku, ale v pripade CR ziju v predstave, ze kdo nema ICO, nemuze vystavit fakturu... je to tak? (anyone?)
Po oznámení živnosti človek už môže podnikať a aj vystavovať faktúry ešte predým, než mu príde pridelené IČO, ale druhá strana ich nemusí prijať (aspoň tak sa vyjadrili na živnostenskom úrade keď som si živnosť zakladal).
Potom som pri vystavovaní faktúry do USA zistil prekvapujúci fakt, že pri vystavení faktúry do zahraničia (alebo aspoň mimo EU) nie sú predpísané ŽIADNE náležitosti, aké musí faktúra obsahovať (a je to teda len na vzájomnej dohode, resp. aby to daňový úrad v druhom štáte akceptoval ako faktúru). Ale nemám to overené.
Človek v slobodnom povolaní môže vystaviť faktúru, ale musí sa registrovať len na daňovom úrade => má len DIČ, nie IČO. Ale ani týmto nie som si celkom istý 
Po oznámení živnosti človek už môže podnikať a aj vystavovať faktúry ešte predým, než mu príde pridelené IČO, ale druhá strana ich nemusí prijať (aspoň tak sa vyjadrili na živnostenskom úrade keď som si živnosť zakladal).Co bude nebo nebude druhá strana přijímat, je věcí dohody. V rámci působnosti obchodního zákoníku lze dohodnout skoro cokoliv. Tedy lze dohodnout, že se nebudou přijímat faktury, kde nebude IČ (pozor, na nových dokumentech je uvedeno IČ, nikoli IČO jako dříve - jen ČSÚ z historických důvodů používá stále IČO).
Potom som pri vystavovaní faktúry do USA zistil prekvapujúci fakt, že pri vystavení faktúry do zahraničia (alebo aspoň mimo EU) nie sú predpísané ŽIADNE náležitosti, aké musí faktúra obsahovať (a je to teda len na vzájomnej dohode, resp. aby to daňový úrad v druhom štáte akceptoval ako faktúru). Ale nemám to overené.Ani vnitrostátní faktury nemají žádné náležitosti. Faktura obecně není účetní ani daňový doklad, i když s ním může být sdružena.
Človek v slobodnom povolaní môže vystaviť faktúru, ale musí sa registrovať len na daňovom úrade => má len DIČ, nie IČO.S vystavováním faktur to nemá nic společného. Registrace na FÚ je povinná podle zákona o dani z příjmů, ale je to čistě jen věc toho, aby jim člověk figuroval v databázi a měli ho trochu víc pod kontrolou. Nic víc.
v pripade CR ziju v predstave, ze kdo nema ICO, nemuze vystavit fakturu... je to tak?Není. Faktura je předpis platby, nic jiného. Fakturovat může kdokoliv, kterákoli právnická osoba, fyzická osoba podnikající jako živnostník nebo pod kterýmkoli jiným zákonem (např. autorským, zemědělským, o elektronických komunikacích...), ale klidně i nepodnikatel, pokud například prodává přebytky ze zahrady nebo má nějaký jiný příležitostný příjem. Faktura jen odběrateli říká, kolik má zaplatit, jakým způsobem a kdy. Faktura stejně musí být podložena nějakou smlouvou (třeba ústní) a její smysl je pouze v tom, že prostě říká, aby odběratel zaplatil. Něco jiného je daňový doklad, ten může vystavit jen plátce DPH. Daňový doklad (může být a bývá kombinován s fakturou, ale také nemusí) musí mít povinné náležitosti, například DIČ obou stran (u zjednodušeného dokladu jen DIČ dodavatele), specifikaci DPH pro jednotlivé položky atd.
Zjednodušený daňový doklad namísto běžného daňového dokladu může vystavit plátce DPH uskutečňující zdanitelná plnění s úplatou za hotové, prostřednictvím platební karty nebo šekem, a to za zdanitelná plnění v ceně obsahující daň celkem nejvýše 10 000 Kč. Zjednodušený daňový doklad může plátce vystavit rovněž za služby, které jsou poskytovány prostřednictvím elektronických prostředků a jejich poskytnutí je podmíněno zaplacením a úplata za tyto služby je prováděna bankovním převodem. Jejich použití není možné v případě prodeje zboží, které je předmětem spotřební daně z lihu a tabákových výrobků za jiné než pevné ceny pro konečného spotřebitele.
Platba na splatnost a zboží => nelze daňový doklad.
zdravim,
hodnotna vec. Na cem jste to postavil (platforma, knihovny) ?
Jak sestavujete vystupni xml dokumenty ?
diky
zdravim,
diky za info.
osobne se par let drzim xslt. Zejmena kvuli dalsimu moznemu refaktoringu a zpracovani xslt sablon. Muze to mit nejake mouchy a je to o neco pracnejsi.
Do ODT vystupu se nejaky cas chystam. Zustava mi vsak hodne nezodpovezenych otazek.
Zeptam se Vas:
0) Osobne z ODT nejasam, nebot neexistuji poradne knihovny. Nebo o nich poradne nevim. Moje predstava je bude apache-fop (ODT ci jiny vystup nikdo zatim nedodelal). Anebo chci knihovnu typu
IText a takto pohodlne vytvaret dokument, bez toho, abych pul roku dopisoval knihovny a pak 2 dny implementoval, co potrebuji. Mate o necem takovem hotovem prehled ?
Chci udelat doslova toto:
ODTDokument doc = new ODTDocument(Styl, Template);
doc.addHeadings(XXX);
doc.addParagraph(XXX);
sekce.addParagraph(XXX);
doc.write(OutputStream.....);
1) jakym stylem vytvarite nejakou zakladni sablonu pro xslt (vzor pro vytvoreni xslt transformace vnitrku ODT dokumentu) ? Osobne se tady obavam toho, ze dokument ma treba spocitane nejake velikosti bloku, layoutu ci jinych elementu a nerad bych dosel k tomu, ze mimo stranky budu jeste dopocitavat, jak ma co byt velke. Osobne bych treba rad zadaval velikosti nekterych bloku a elementu procenticky. Jde to ?
diky
content.xml. Vysledkem je neuveritelne neprehledny dokument, kde samotna data zacinaji az treba ve 3/4 dokumentu a ktery nezachrani ani (oproti OOXML) relativne konzistentni a samopopisne pojmenovani tagu a atributu. OOXML je mozna lehce krypticky, ale jestli je v nem (a v Excelu) neco dotazeno, pak je to modularnost. Vysledek je ten, ze se mi s nim v tomto pripade pracovalo lepe. (Dokument popisujici standard OOXML je take mj. mnohem lepe zpracovan, lepe prolinkovan a strukturovan. U kazdeho elementu mate odkazy na elementy, ktere muzou byt jeho rodici, jeho potomky a tabulkovy vypis vsech moznych atributu. ODF 1.0 je oproti tomu mizerne zpracovan...)
0) Osobne se knihovnam tohoto typu vyhybam, at uz jde o PDF ci neco jineho, protoze z me zkusenosti je to jen otazka casu, nez se dostanete do bodu, kdy potrebujete neco, co API dane knihovny nenabizi a pak implementaci takove veci zabijete vic casu, nez kdybyste to cele udelal nejakym low-level systemem -- coz je to, co ja preferuju, tedy treba to XSLT. Protoze jsem to psal v PHP, neimplementoval jsem PDF, protoze XSL-FO z PHP neni zrovna standardni zalezitost...
1) Delal jsem to tak, ze jsem faktury jednoduse ulozil jako ODF a OOXML, extrahoval co je potreba generovat (content.xml, resp. sheet1.xml) a predelal to na XSL sablonu. Delal jsem to tak, aby pri pouziti zvoleneho fontu nebo nejakeho proporcne podobneho faktura nepretekla pres 1 stranku. Pokud jde o nastaveni okraju, ODF 1.0 pouziva atributy z NS urn:oasis:names:tc:opendocument:xmlns:xsl-fo-compatible:1.0 a ty procentualni zadani umoznuji. Novejsi specky ODF ted nemam po ruce... (vsimnete si, ze to neni NS XSL-FO, pouze ten standard vybrakovali -- jedna z tech vice znamych "prijemnosti" u ODF)
Chybně vyplněná políčka jsou nadepsány včetně html značek <p> kolem.
CAPTCHA vypadá jako case sensitive a to je vážně pruda. Nehledě na nerozeznatelnost nuly a písmene o.
A ještě dále uvítal bych ukázkový výstup ke stažení, abych měl představu, jak to vypadá, aniž bych musel vypisovat spoustu falešných údajů.
Uz me napadlo, ze ta captcha je dost tvrda...
Ta chyba policka opravim, dik.