Prográmek na faktury

13.1.2012 03:20 | Přečteno: 4005× | ostatní | | poslední úprava: 13.1.2012 13:37

Snad mě nebudete kamenovat za off-topic zápisek, který nesouvisí ani s politikou, ani s řízením automobilu, ani s amatérskou psychoterapií. Před časem jsem se tu v blogu nebo v poradně ptal, jestli někdo nemá k dispozici šablonu pro tvorbu PDF faktur a moc jsem nedopadl...

A tak jsem používal, co se dalo. Nejdřív jsem vytvářel faktury v OpenOffice Calc, což vypadalo celkem dobře, tedy až na naprostou absenci oddělení dat a vzhledu. Kvůli tomu jsem se zdržoval nesmysly jako je kopírování řádků, vyrovnávání výšek řádků, a napravování různých atributů písma, převáděním do PDF, prostě celkovým nepohodlím.

O nepořádku v adresářích, kde se nacházely jak zdrojové soubory, tak výsledná PDF, ani nemluvě.

Tvorba PDF

Po roce a půl živnosti jsem, pochopitelně v lednu, několik dní patlal LaTeXovskou šablonu pro tvorbu PDF faktur. TeX/LaTeX se ukázal jako nepříliš vhodný, leč dosud nejvhodnější nástroj. Patlání s XSL:FO jsem vyhodnotil jako neúčelné a jinou smysluplnou alternativu jsem neobjevil. LaTeX tedy zůstal.

Aktuální šablona vypadá takto:

\documentclass[10pt]{article}
\usepackage[utf8]{inputenc}
\usepackage[czech]{babel}
\usepackage{a4wide}
\usepackage{tabularx}
\renewcommand{\familydefault}{\sfdefault}
\setlength{\extrarowheight}{3pt}

\begin{document}
\footnotesize

\begin{center}
\begin{tabularx}{\textwidth}{|XXXX|}
\cline{3-4}
\multicolumn{2}{X}{} & \multicolumn{2}{|X|}{} \\
\multicolumn{2}{X}{} & \multicolumn{2}{|l|}{\large Faktura: \hfill {{invoice.number}}} \\
\multicolumn{2}{X}{} & \multicolumn{2}{|X|}{} \\
\hline
& & & \\
\bf Dodavatel: & & \bf Odběratel & \\[1em]
\multicolumn{2}{|l}{\large\bf {{issuer.name}}} & \multicolumn{2}{l|}{\large\bf {{customer.name}}} \\
{{py:
a1 = issuer.address[:]
a2 = customer.address[:]
a1 += (len(a2)-len(a1))*[""]
a2 += (len(a1)-len(a2))*[""]
}}
{{for f1, f2 in zip(a1, a2)}}
\multicolumn{2}{|l}{\large {{f1}}} & \multicolumn{2}{l|}{\large {{f2}}} \\
{{endfor}}

& & & \\
\multicolumn{2}{|l}{IČ: {{issuer.number}}} & \multicolumn{2}{l|}{IČ: {{customer.number}}} \\
& & & \\

{{py:
a1 = issuer.comments[:]
a2 = customer.comments[:]
a1 += (len(a2)-len(a1))*[""]
a2 += (len(a1)-len(a2))*[""]
}}
{{for f1, f2 in zip(a1, a2)}}
\multicolumn{2}{|l}{ {{f1}}} & \multicolumn{2}{l|}{ {{f2}}} \\
{{endfor}}

& & & \\
\hline
& & & \\
\bf Platební podmínky: & & & \\[1em]
\large Forma úhrady: & \large {{"hotově" if invoice.payment=="cash" else "převodem"}} & \large Datum vystavení: & \multicolumn{1}{r|}{\large {{invoice.date.strftime("%d.%m.%Y")}}} \\
\large Číslo účtu: & \large {{issuer.bank_account}} & \multicolumn{2}{l|}{\large\bf Datum splatnosti: \hfill {{invoice.due.strftime("%d.%m.%Y")}}} \\
\large Variabilní symbol: & \large {{invoice.number}} & & \\

{{if invoice.notes}}
& & & \\
\hline
& & & \\
\bf Poznámky: & & & \\[1em]
{{for note in invoice.notes}}
\multicolumn{4}{|l|}{\large {{note}}} \\
{{endfor}}
{{endif}}

& & & \\
\hline
& & & \\
\bf Fakturujeme vám: & & & \\[1em]

{{for item in invoice.items}}
\multicolumn{4}{|l|}{\normalsize {{item[0]}} \hfill {{item[1]}} Kč} \\
{{endfor}}

& & & \\
\hline
& & & \\
\large\bf Celkem k úhradě: & & & \multicolumn{1}{r|}{\large\bf {{invoice.sum}} Kč} \\
& & & \\
\hline
\end{tabularx}
\end{center}

\end{document}

Tahle část bude asi nejprasáčtější. TeX obecně nepoužívám z nadšení, ale protože jsem nic lepšího neobjevil.

Datové formáty

Specifikace datových formátů byla od začátku jednoduchá. Co vložený záznam, to soubor. Soubory seskupené do adresářů podle typu. Formát textový. Vše se odvíjelo od toho, že jsem data připravoval ve vimu víceméně nezávisle na případné budoucí implementaci. První implementace obsahovala pouze skript na vyrobení PDF ze souboru faktury a souborů s invormacemi o mně a o zákazníkovi. Notace připomíná tu, co se používá například u HTTP nebo mailových hlaviček, ale to je spíše implementační detail.

Příklad dnes vydané faktury s číslem 2012003 (interně faktura č. 3) pro firmu xyz o dvou položkách s třicetidenní splatností:

Item: 10000: Práce všeho druhu I
Item: 15000: Práce všeho druhu II
Due: +30

Část informací se skrývá v názvu souboru: 20120113-003-xyz, detaily o firmě XYZ jsou v samostatném souboru podobnémo formátu. Jednoduché, že?

Shellovské skripty

Jako první „nevinné“ vychytávky byly příkazy pro rychlé vytvoření nové faktury a otevření ve vimu, reeditace poslední faktury, přegenerování PDF a nakonec i zobrazení PDF. Celé to bylo ve formě shellovských skriptů v adresáři jinak určeném pro data. Pilířem zpracování byly krátké skriptí v awk a sedu volané ze zmíněných shellovských skriptů. Podobně by posloužily i základní konstrukce Perlu.

V podstatě jsem byl až na pár detailů spokojený. Vadilo mi snad akorát, že se jedná o skripty naplácané mezi data, a že bych se styděl jejich obsah zveřejnit. A taky, že každé rozšíření stávajícího toolsetu mě stálo docela dost práce. Chtělo to jeden konzolový prográmek s podpříkazy který by vše obstarával, ale k tomu jsem se odhodlal až po dalších dvou letech vylepšování stávajícího systému. Samozřejmě bylo možné zůstat u shellovských skriptů, jen v nich udělat trochu pořádek, ale cílovým jazykem se nakonec stal Python 3.2.

Přepis do Pythonu

Tak abychom začli. Zadáním (mým osobním) bylo vytvořit Pythoní CLI prográmek s velice jednoduchými podpříkazy. Požadavkem číslo jedna byla 100% zpětná kompatibilita s použitým datovým formátem, se kterým jsem spokojený, tedy přímočará náhrada stávajících skriptů. Dále takové přirozené věci jako přísnější kontroly, o co si uživatel řekne, pohodlnější workflow, a tak podobně.

Výsledek je jakž takž uhlazený, ale doporučoval bych ho spíše lidem, kteří se nebojí sáhnout do (cizího) Pythoního kódu.

Keců bylo dost...

Zdrojový kód

git clone git://git.pavlix.net/invoice

Něco málo k použití se najde v README, zbytek ve zdrojácích. Celý program je postavený tak, aby splnil svůj účel zapadl do stávajícího workflow. Nápady? Připomínky? Patche? Pull requesty?

       

Komentáře

[Bedňa]

Kedysi som mal program kde som si upravoval šablóny sám, bol to čistý texťák, typu:

$logo
-----------------------------------------------
Faktúra: $invoice     |  Dátum: $date
-----------------------------------------------
Dodávateľ: $supplier  |  Odberateľ: $purchaser
-----------------------------------------------
Forma úhrady: $payment
-----------------------------------------------
atď.

Program všetko vytlačil ako si to spravil v texťáku, len nahradil názvy premenných ich obsahom.

V Latexe sa nevyznám a Python kód môžem odskúšať až tak doma, ale pochopil som, že to aj samo čísluje faktúry, to by sa dalo potom použiť aj pre knihu vydaných faktúr.

Nad niečim podobným som uvažoval, ale robil by som to cez prehliadač, aby sa dala napríklad vytlačiť faktúra aj u zákazníka priamo. To len na inšpiráciu :)

Inak kto by potreboval účtovníctvo na pár faktúr Flexibee má zdarma verziu, z hlavy si už nepamätám na koľko účtovných operácií.

[pavlix]

V Latexe sa nevyznám a Python kód môžem odskúšať až tak doma, ale pochopil som, že to aj samo čísluje faktúry, to by sa dalo potom použiť aj pre knihu vydaných faktúr.

V těch shellovských skriptech jsem měl skript na vyrobení texťáku s přehledem za daný rok, podle čehož vím mimojiné kdo zaplatil a taky se dá z toho opisovat do daňového přiznání a přehledů pro pojišťovny.

Do toho Pythonu to budu muset ještě něco dodělat.

Nad niečim podobným som uvažoval, ale robil by som to cez prehliadač, aby sa dala napríklad vytlačiť faktúra aj u zákazníka priamo. To len na inšpiráciu :)

Mno je to postavené jako knihovna a je to non-copyleft opensource, takže by nad tím mělo jít postavit i webové UI.

Inak kto by potreboval účtovníctvo na pár faktúr Flexibee má zdarma verziu, z hlavy si už nepamätám na koľko účtovných operácií.

Jojo, vím o tom, ale tenhle CLI přístup mi vyhovuje víc.

[Ladicek]

Inak kto by potreboval účtovníctvo na pár faktúr Flexibee má zdarma verziu, z hlavy si už nepamätám na koľko účtovných operácií.

Jojo, vím o tom, ale tenhle CLI přístup mi vyhovuje víc.

Kdysi jsem uvažoval o tom, že bych pro FlexiBee napsal aspoň základního cmdline klienta (přes REST API), ale v pracovní době mi to asi Ferš nedovolí a ve volným čase mám lepší věci na práci Ale šlo by to.

[pavlix]

No jako pokud by to bylo srovnatelně či lépe použitelné, než můj výše uvedený program, tak bych si příští rok asi rozmyslel věnovat čas jeho vylepšování, vzhledem k tomu, za kolik ten čas normálně prodávám. Současný stav bych prohlásil za pěkné vyzkoušení, vydal jako public domain (erm... to už jsem vlastně udělal), a nechal svému osudu.

[CET]

Taky jsem pouzival TeX/LaTeX. Ale kua, ty tam mas python! Ja to bastlil kompletne v TeXu, ale nic jsem tam nepocital, mel jsem to jako cisty texty, jen proste na sformatovani. Ja to resil tak, ze jsem mel template s makrama a vyslednou fakturu jsem udelal jako novy soubor, includnul ten template, nastavil hodnoty a kompiloval ten soubor. Samozrejme jsem mohl kopirovat uz starsi faktury a jenom upravovat udaje. Prakticky by to slo generovat z jinyho nastroje, ale ja mel par faktur, tak jsem to delal rucne.

[pavlix]

Tak do toho bych nešel :). Před pythonem to bylo v shellu a awk.

[pavlix]

Příloha:

• 20120112-050-test.pdf (28586 bytů)

Jednu testovací fakturu tu ještě mám, tak aspoň nemusím hledat, co by se dalo zveřejnit :).

[pavlix]

Ale pokud někdo vyrobíte hezčí šablonu, tak klidně budu používat tu :).

[dad]

uz 50 faktur v tomhle roce? Respekt.

[xkucf03]

Tak pokud jsou všechny na 0 Kč…

[Bedňa]

Účtuje v binárnej sústave na prvej bola jednička

[pavlix]

Mno... zaprvé 50 faktur není tak moc, záleží, co je na nich za částku, a za druhé bys mě spíš mě politovat, protože to je z řady testovacích faktur první, která vykazovala správný výstup, ale to ještě byla generována mnohokrát opakovaně, takže ve skutečnosti by ses dostal daleko za stovku, kdybys počítal všechny pokusy o vygenerování.

Jinak se dívám na loňský rok, tak tam mám necelých třicet faktur.

[zenhas]

Taky jsem to tak dělal. Pro pár faktur to jde. Doba, kterou bych strávil vytvářením lepšího řešení byla větší než ta, kterou jsem věnoval recyklaci jedné faktury do další. :)

[alfonz mucha]

můžeš ukázat jak vypadá výstup jak z toho původního latexu a i z pythonu?

Jinak v práci se řídíme slovem ERP > Excel runs production. Takže používáme jednu několik tabulek s výstupy. Data jsou oddělená a načítají se automaticky. Myslím, že obecně co se týče možností a přizpůsobivosti a možnostmi vstupů a výstupů jsou systémy postavené na calcu/excelu vynikající. Jejich rychlost je obvykle dostačující a splňují i dobrou přenositelnost. Jediný problém může být uživatelská přívětivost

[alfonz mucha]

jinak ukázka co v současnosti máme napsané v Calcu je vidět na www.dlauhy.cz

[pavlix]

můžeš ukázat jak vypadá výstup jak z toho původního latexu a i z pythonu?

Výstup se neměnil... LaTeXovská šablona se měnila jenom z technické stránky, výstup používám stejný.

[pavlix]

Příloha:

• 20120112-050-test.pdf (28586 bytů)

Ukázka.

[alfonz mucha]

Plánuješ to nějak postupně rozšiřovat? nebo vyhovuje, že je jen takové "malé udělátko"?

Respektive zajímal by mě názor celé komunity okolo ABC a čtenářů, jaký mají názor na tyhle malé aplikace, které si člověk píše pro svojí potřebu. Případně názor zda je lepší jít do plnohodnotného software / dělat si software na zakázku a postupně zlepšovat? Jde mi spíše o obecný pohled na věc (nezáleží tedy na tom, zda je to malá aplikace, nebo kalkulačka v tabulkovém procesoru).

[pavlix]

Plánuješ to nějak postupně rozšiřovat? nebo vyhovuje, že je jen takové "malé udělátko"?

Tak jak to je, mi to vyhovuje až na několik TODO položek, ale TODO zatím obsahuje jenom textový přehled a přidání příkazu na označení data zaplacení (obojí věci, které předchozí systém napsaný v shellu měl).

Nebráním se rozšiřování, pokud na to někdo má čas, patche, které jsou na první pohled užitečné a nerozbíjí stávající funkcionalitu rád začlením do svého stromu a budu udržovat, ale neměly by to být věci pro mě vyloženě zbytečné.

Třeba v případě patchů přidávajících podporu DPH bych asi dal přednost tomu, kdyby autor patche převzal správu nad hlavním stromem, nebo alespoň úzce spolupracoval kvůli testování. V tuhle chvíli všechno, co software obsahuje, jsem už někdy použil a pravděpodobně znovu použiju.

Respektive zajímal by mě názor celé komunity okolo ABC a čtenářů, jaký mají názor na tyhle malé aplikace, které si člověk píše pro svojí potřebu.

Pokud by existovala srovnatelná open source aplikace, určitě bych dal přednost použití té a zasílání bugreportů a patchů jim.

Pokud by existovala srovnatelná closed source aplikace za rozumnou cenu, ideálně s RPM balíčkem a repozitářem s updaty, která by plně vyhovovala, nejspíš bych jí dal z ekonomických důvodů taky přednost.

Případně názor zda je lepší jít do plnohodnotného software / dělat si software na zakázku a postupně zlepšovat?

Pokud by „plnohodnotný“ software nabízel to, co potřebuju, využil bych ho :). Obecně.

[Dalibor Smolík]

Trochu jsem to taky zkoušel, ale upustil jsem od toho. Dodnes vytvářím faktury v php a připojuji je pak v e-mailu ve formátu HTML ..

[pavlix]

No... tak to mi přijde dost podobné, až na výstupní formát, kde PDF vyhovuje víc.

[Dalibor Smolík]

Každopádně to vypadá profesionálněji.

[pavlix]

Jestli, tak opravdu jen vypadá :).

[M-train]

Jsem taky pro PDF a převádím si do něj i obdržené faktury. Výhodou je, že se s nima dá i dodatečně 'pracovat'.

Jinak dělám skoro všechno s cizinou, kde je všechno JENOM přes mejl jako příloha, tj. bez razítek i ručních podpisu. Jsou země, kde je dokonce zakázáno posílat papírové faktury kvůli ochraně životního prostředí, aspoň na státní a veřejné instituce - požadují pouze elektronickou formu a jinou ani neproplatí.

[xkucf03]

zakázáno posílat papírové faktury kvůli ochraně životního prostředí

Z tohoto důvodu bych zakázat tvorbu nových zákonů a směrnic. (ještě teď mám doma štos ÚZ, které jsou ale neaktuální a na nic)

[havoc]

... Dodnes vytvářím faktury v php a připojuji je pak v e-mailu ve formátu HTML ..

Tak s HTML fakturama mám dost špatnou zkušenost, hlavně s jejich tiskem. Často vypadají jinak i rozhozeně podle toho v jakém prohlížeči se otevřou, jak jsou nastaveny výchozí fonty, jaké je aktuální DPI obrazovky apod.

[Dalibor Smolík]

Souhlas. Stejně je tisknu já (takže problém si vyřeším) a posílám originál s razítkem a podpisem, e-mailová kopie slouží jen k informaci o nakládce, případně pro úhradu.

[pavlix]

Popravdě řečeno papírové používám výjimečně. Radši jsem si na web napsal, že papírové zpoplatňuju 100 Kč, ale normálním zákazníkům dám papírovou verzi samozřejmě zdarma.

[Dalibor Smolík]

Docela bych rád viděl, jak vypadá nenormální zákazník , ale vážně - v mém oboru jsou zákazníci ještě konzervativní. Co je psáno, to je dáno.

[pavlix]

V tomhle případě to používám v naprosto specifickém subjektivním smyslu, pro který jsem nenašel jiný slušný výraz. Normální zákazník je u mě takový zákazník, kterého nemám chuť poslat do prdele. Stává se to výjimečně, ale člověk na ně musí mít něco připraveno.

Rozdíl mezi normálním zákazníkem, co potřebuje papírovou fakturu, a blbem, se pozná už na způsobu podání informací:

Blb: „Tohle vám nikdo nezaplatí. Musíte nám přivézt papírovou fakturu s datem a podpisem.“

„Normální“ zákazník: „Můžete/můžeš nám prosím tu fakturu dát na papíře podepsanou?“

Ten normální mi to navíc obvykle dává vědět v době, kdy se k němu chystám, případně na místě, abych nemusel kvůli faktuře jet znovu nebo jít na poštu.

[pavlix]

nemám chuť poslat do prdele. Stává se to výjimečně

Teď jsem si naběhl s nejednoznačností :). Samozřejmě se výjimečně stává ten špatný případ.

[Dalibor Smolík]

A dvojitý blb je ten, kterému pošlu fakturu poštou a doporučeně a ozve se, že ji potřebuje dvakrát )) i to se mi už stalo

[Bedňa]

Tak mu odpíš, že ju zasielaš za dvojitú platbu

[pavlix]

:)

[xHire]

Shodou okolností jsem si také pro letošní rok napsal program na správu faktur, byť webový (v Ruby on Rails). :c) Nechávám je sázet také v LaTeXu, akorát ještě nemám dořešené digitální podpisy u výstupních PDFek (zatím nemám zákonnou povinnost je tam mít, ale chtěl bych je). Časem přidám i podporu pro ISDOC.

Tvoje šablona mi skutečně připadá jako následovnice faktur z Calcu (nejen vzhledem, ale i tou jednou velkou tabulkou ;c)). A také neřeší přechody na další stránku (ale pokud nemáš takové objemy položek k fakturaci, tak je to celkem pochopitelné; já se to raději snažím vyřešit předem, abych předešel potenciálním problémům, když už budu fakturovat automatizovaně).

[pavlix]

Tvoje šablona mi skutečně připadá jako následovnice faktur z Calcu (nejen vzhledem, ale i tou jednou velkou tabulkou ;c)).

Podle čeho myslíš, že jsem ji modeloval? :) Mně zabralo nejmíň dva dny vrtání se v tom LaTeXu, natož abych ještě vymýšlel nějaký neotřelý tvar faktury :).

A také neřeší přechody na další stránku (ale pokud nemáš takové objemy položek k fakturaci, tak je to celkem pochopitelné;

Mívám jednu položku. Maximálně dvě :). Kecám, nedávno jsem vydal fakturu o třech položkách.

Taky mi tam chybí cena za kus, počet kusů, atd, protože v 99% položek je počet kusů 1 a když výjimečně ne, tak to píšu přímo do textu.

já se to raději snažím vyřešit předem, abych předešel potenciálním problémům, když už budu fakturovat automatizovaně).

Jo, to se mě momentálně netýká, navíc jsem vždycky doufal, že se toho LaTeXu časem zbavím a budu to generovat něčím příjemnějším.

[Käyttäjä 11133]

Ukázka výstupu? :)

[pavlix]

Příloha:

• 20120112-050-test.pdf (28586 bytů)

Nedával jsem ji, není tak důležitá, LaTeX šablona se dá upravit.

[Radek Hladik]

Já jsem vcelku spokojený s mPDF. Mám udělané URL, kterému pošlu HTML a dostanu zpátky PDF. V případě, kdy pošlu standardní HTML, obdržím slušné PDF (správná čeština je samozřejmost). Rozhodně na takovou fakturu, jako jsem viděl v ukázce, by to bylo postačující. Dokonce to i poměrně pěkně rozdělí tabulku, pokud je dlouhá a vůbec je to docela elegantní. Pokud chci pokročilejší PDF funkce nebo formátování, upravím HTML tak, aby obsahovalo speciální tagy (třeba pagebreak) a případně předám další parametry (autor PDF atd...).

Ještě jsem si to vylepšil o data URL, takže veškeré obrázky jsou přímo v tom HTML. To mám kvůli snazší archivaci a kvůli jednoduššímu použítí ze systémů, kde se uživatel autentizuje. Co mi naopak vadí je absence jednoduché podpory pro podpisování, ale i to prý nějak jde, jen je to docela složité.

Ale v principu je to zatím nejjednodušší způsob jak snadno vyrábět rozumně hezky vypadající PDF, který jsem objevil.

[pavlix]

správná čeština je samozřejmost

No, to u LaTeXu je správná čeština jen na pohled. Při označování v PDF prohlížeči se prozradí, že je to nějak strašně spatláno či co.

Pokud chci pokročilejší PDF funkce nebo formátování, upravím HTML tak, aby obsahovalo speciální tagy (třeba pagebreak) a případně předám další parametry (autor PDF atd...).

To zní pěkně, akorát by se mi to líbilo ve formě knihovny nebo příkazu, bez HTTP mezivrstvy.

Každopádně nějaký html2pdf skriptík budu potřebovat taky, zase kvůli webu, ale zatím mi to nefungovalo (špatné kódování znaků).

[Někdo jiný]

Ta čeština se dá opravit:

\usepackage[T1]{fontenc}
\usepackage{lmodern}

Minimálně v Evince se potom dá text normálně vykopírovat, jinde jsem to nezkoušel.

[pavlix]

Díky, zatím to vypadá v pořádku.

[xHire]

správná čeština je samozřejmost

No, to u LaTeXu je správná čeština jen na pohled. Při označování v PDF prohlížeči se prozradí, že je to nějak strašně spatláno či co.

LaTeX to umí vysázet dobře, když se mu o to řekne.

[pavlix]

Přesně tak, LaTeX není hotový produkt. Aby pracoval správně, musí se ukecávat. Dokumentace je nedostatek a mezi webovými zdroji se špatně rozlišuje zastaralý zdroj, špatný aktuální zdroj a dobrý zdroj, jsou IMO dosti protichůdné.

Ale jak už jsem říkal, nic lepšího k dispozici momentálně nemám. Ještě jsem mohl zkusit přímé generování PDF.

[xHire]

To máš naprostou pravdu. On toho umí tolik, že na to sotva stačí pár článků, na které člověk sem tam narazí. Už mám doma jednu bichli, koncem minulého roku jsem přikoupil ještě jednu knížku, tak snad mi to pomůže. Ale sehnat něco u nás je občas docela problém.

[Radek Hladik]

Příloha:

• demo.pdf (59970 bytů)

Každopádně nějaký html2pdf skriptík budu potřebovat taky, zase kvůli webu, ale zatím mi to nefungovalo (špatné kódování znaků).

To je přesně to, co jsem měl na mysli s tím, že čeština je v pořádku. Zatím všechny html2pdf konvertory mi zmršily češtinu nebo to byl neskutečný boj a výsledek nebyl úplně ideální.

Při označování v PDF prohlížeči se prozradí, že je to nějak strašně spatláno či co.

Copy paste z ukázkového PDF: Měsíční přehled transitních přenosů pro zákazníka

To zní pěkně, akorát by se mi to líbilo ve formě knihovny nebo příkazu, bez HTTP mezivrstvy.

Tak je to PHP knihovna, není problém si jí přímo použít nebo volat přes CLI. Ale mně se ta možnost přes HTTP poměrně líbí, takže to mám takto.

Přikládám ukázku, trochu jsem to vykuchal a druhou tabulku uměle nafoukl, ať je vidět, jak to automaticky zopakuje záhlaví tabulky. A není tam záhlaví a zápatí stránky, ale to se jednoduše dělá jako další dva kusy HTML. A dobře funguje i to "Stran 3", kdy to spočítá strany ve výsledném PDF a i v zápatí je pak možné mít strana 1/3.

[alfonz mucha]

Můžu se zeptat co znamená hezky vypadající PDF? Můžete ukázat?

Jinak nevyplatí se v tomto případě například Inkscape (dávková úprava textu v svg) a pak využití tiskového/exportního subsystému v řádce?

[Radek Hladik]

Ukázka viz výše.

[Spike]

Hledal jsem různé tabulky, účetní programy, skripty a nakonec jsem svá veledůležitá data svěřil "cloudu" a mám klid. :)

[Dalibor Smolík]

Trochu adrenalin, ale taky řešení.

[pavlix]

Znal jsem :).

[Fakturoid]

To jsem rád člověče, jen mám drobnou výhradu. Když se podívám do zrcadla, tak nevidím mrak, ale robota.

[Espinosa]

Zkoušel jsi napsat makro v Calcu? Lze to programovat v StarBasicu, JavaScriptu, Pythonu, Javě nebo C++. Mít šablonu a data sosat z jiného souboru, nebo lépe přímo z SQL databáze a generovat vyplněná PDFka. OOo by se měla zvládnout nakonektit na SQL databázi (StarBasic), případně v Javě použiješ JDBC.

StarBasic, jazyk nic moc, ale o krásu jazyka tu nejde, nepíšeš sonety ale účelový program. Má to integrované IDE přímo v OOo, včetně editoru kódu a debuggeru. Psal jsem pro přítelkyni hromadnou úpravu vzhledu tabulek podle obsahu v 500ti stránkové doktorské práci. Na fóru OOo najdeš řadu užitečných ukázek, občas jsem musel ale Googlit i experimentovat. Hodně pomohla introspekce objektů při ladění. Je to intuitivnější, než se na první pohled zdá.

[pavlix]

Zkoušel jsi napsat makro v Calcu? Lze to programovat v StarBasicu, JavaScriptu, Pythonu, Javě nebo C++. Mít šablonu a data sosat z jiného souboru, nebo lépe přímo z SQL databáze a generovat vyplněná PDFka. OOo by se měla zvládnout nakonektit na SQL databázi (StarBasic), případně v Javě použiješ JDBC.

Neměl jsem k tomu důvod, jak už jsem psal v blogpostu, Calc nevyhovoval.

[Espinosa]

Jestli se jedná "jen" o tohle:

Nejdřív jsem vytvářel faktury v OpenOffice Calc, což vypadalo celkem dobře, tedy až na naprostou absenci oddělení dat a vzhledu. Kvůli tomu jsem se zdržoval nesmysly jako je kopírování řádků, vyrovnávání výšek řádků, a napravování různých atributů písma, převáděním do PDF,

..pak by to mělo jít makrem vyřešit. Speciálně "absenci oddělení dat a vzhledu" snadno.
U ostatního, bez znalosti bližších detailů, pracnost lze těžko určit.

[pavlix]

..pak by to mělo jít makrem vyřešit. Speciálně "absenci oddělení dat a vzhledu" snadno.

Jako za tenhle tip samozřejmě děkuju, i když ho v tomhle případě nevyužiju a ty makra nebudu psát asi nikdy. Ale možná to použiju, až budu zase s někým dělat analýzu a makra nechám na někom, kdo to už umí.

U ostatního, bez znalosti bližších detailů, pracnost lze těžko určit.

Jednou z mých podmínek bylo, aby to bylo alespoň stejně pohodlné jako můj systém (a, ale to jsem předtím nepsal. Samozřejmě subjektivně.

V tuhle chvíli mi faktura zabere několik málo vteřin, když nepočítám vymyšlení popisu toho, co se tak děje. To znamená, že v těch lepších případech mám hotovo dřív, než se „Office“ aplikace vůbec spustí.

Až napíšeš makro, které dokáže všechny moje důvody proti Office eliminovat, koupím ho od tebe :).

[pavlix]

Jednou z mých podmínek bylo, aby to bylo alespoň stejně pohodlné jako můj systém (a, ale to jsem předtím nepsal. Samozřejmě subjektivně.

Zmizel mi kus textu a ztratilo to původní význam, tedy opravuju:

Jednou z mých podmínek bylo, aby to bylo alespoň stejně pohodlné jako můj systém (a, ale to jsem předtím nepsal, stejně pohodlné jako to, v co se může můj systém během roku vyvinout. Samozřejmě subjektivně.

[jeleniste]

Pěkný, šikovný. Přesně tohle jsem hledal a byl jsem línej se s tim sám patlat. Díky. Hodí se. Akorát osobně by se mi líbilo, kdyby to neukládalo do texťáků, ale do db, třeba do sqlite, teda uplně nejlepší by bylo, kdyby si to umělo ty itemy samo nažrat z hamsteřího sqlite. Jakože neni asi těžký si to generovat do nový faktury dotazem.

[petrsss7]

ja preferuju toto https://imboss.cz/ libi se mi ze tam mas qr kody atd