Faktury-online.cz: generátor faktur v ODF, OOXML a XHTML (diskuse)

[pasmen]

Tohle také používám. V jedné ze svých aplikaček plním přes Smarty šablony smluv právě v ODT. Je to ideální, dokonce (za použití odpovídajícího fontu) mi to tam tiskne i čarový kód. Nemůžeme si to vynachválit.

[=^..^= AmigaPower®]

Dobrý

PS: SKK jsou slovenský koruny? To ještě funguje?

[Daniel Kvasnička ml.]

hehe, vidis, ja to mel celkem dlouho v supliku opraveno.

[=^..^= AmigaPower®]

V pohodě, server bankier.pl ještě do nedávna vedl aktuální kurz (nevim jak a na co), tak jsem si říkal, že se to třeba ještě používá (a možná i jo co? na nějaký splátky na starý smlouvy...??).

[Michal Fecko]

No predsa pre Nowy Sącz a Nowy Targ - a ich obchodnikov ktori si este nestihli zmenit SKK za ZL ci EURa

[Luk]

Je tam napsáno "Variabilní symbol (pokud necháte prázdné, bude použito číslo faktury)". Jenže když to nechám prázdné, nic se nepoužije (bude to prostě prázdné).

[Daniel Kvasnička ml.]

Melo by byt OK, diky za report.

[Radovan Garabík]

1. chcelo by to lokalizáciu, aby sme to aj my bratia mohli používať (UI netreba, len výsledná vygenerovaná faktúra)
2. Banka a Bankový účet by nemali byť povinné položky, keďže faktúru možno dať aj splatnú v hotovosti
3. chýba možnosť uhradiť faktúru vzájomným započítaním pohľadávok
4. môže byť odberateľ  zo zahraničia? (chýbajúce položky v adrese a SWIFT & adresa banky)
5. 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.

[Luk]

chýba možnosť uhradiť faktúru vzájomným započítaním pohľadávok

Spíš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.

[Daniel Kvasnička ml.]

Spíše chybí možnost tam napsat cokoli vlastního

To by jiz ted melo byt mozne. ICO a DIC jsem udelal obe nepovinne.

[Daniel Kvasnička ml.]

Dik za seznam

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 hotovosti

Uz nejsou

chýba možnosť uhradiť faktúru vzájomným započítaním pohľadávok

Ta 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?)

[Radovan Garabík]

 

 

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ý

 

[Luk]

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.

[Luk]

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.

[ZAH]

Pro upřesnění zjednodušený daňový doklad lze vystavit pouze. 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.

[ZAH]

Ta skleroza samozřejmě zjednodušený daňový doklad. Omlouvám se.

[Pavel Kysilka (goldenfish)]

zdravim,

 

hodnotna vec. Na cem jste to postavil (platforma, knihovny) ?

Jak sestavujete vystupni xml dokumenty ?

diky

[Daniel Kvasnička ml.]

No, mel jsem to rok, mozna vic, v supliku, takze to stoji na vecech, ktere bych dnes uz asi nezvolil, nebo minimalne z casti volil jinak. Zakladem je PHP framework CodeIgniter (dnes bych volil Kohanu nebo cisty Zend, pokud bych vubec volil PHP), view vrstva i generovani dokumentu je komplet vse XSLT. Dneska bych sablony asi delal pres PHPTAL (kdyby PHP), dokumenty mozna taktez, i kdyz XSLT mi dost vyhovuje a je pro me dost flexibilni. Mam sablony archivu a do nich "vstriknu" generovane casti (XHTML je prirozene jen jedna samostatna sablona...).

Pokud by se to dal rozvijelo smerem k sluzbe s uzivatelskymi ucty, byla by to nejspis separatni aplikace v Jave (Spring, Stripes, JSP). Mozna bych zkusil javi App Engine... Ale to neni jeste finalni rozhodnuti...

[User682]

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

[Daniel Kvasnička ml.]

Taky z ODT nejasam, i kdyz spise to bude OpenOfficem. Jeho specialita je rvat vsechno do 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)

[Kamil Páral]

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.

[Kamil Páral]

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

[Daniel Kvasnička ml.]

Dobry napad...

[Daniel Kvasnička ml.]

Nula se rozeznat da, ale chce to trochu cvik... Uz me napadlo, ze ta captcha je dost tvrda...

Ta chyba policka opravim, dik.

[xHire]

Občas se hodí generování faktury přímo do PDF, aby člověk mohl vygenerovanou fakturu ihned distribuovat dál, aniž by se musel zdržovat jejím otevřením a přeuložením.

[Daniel Kvasnička ml.]

To je fakt, ale me v tomto pripade slo konkretne o otevrene formaty zalozene na XML. Generovat pdf z php s takovou mirou ovlivnitelnosti, jako mam pri generovani ODF ci OOXML s pouzitim XSLT, neni sranda... Jestli to budu vyvijet dal a dojde na Javu, pak zapojim XSL-FO a bude i PDF. Rozhodne nechci pouzivat knihovny, co tvorbu PDF abstrahuji do nejakeho omezeneho API...

[Kroko]

Koukam že nápad co mi pár let leží v hlavě a nebyl čas realizovat už někdo realizoval ...