- Questo topic ha 6 risposte, 3 partecipanti ed è stato aggiornato l'ultima volta 12 anni, 4 mesi fa da
robitex.
-
CreatoreTopic
-
14 Aprile 2014 alle 21:58 #93981
-
CreatoreTopic
-
AutoreRisposte
-
-
15 Aprile 2014 alle 4:27 #93982::
Già; credo che tu debba crearti una classe ad hoc; prova a vedere la guida tematica sulle classi, qui sopra nella sezione Documentazione.
Ricorda: il logo tuo va nella testatina, il logo del cliente, ammesso che in un preventivo ci voglia, va nel copro del messaggio.
Se vuoi una intestazione che contenga due riquadri, uno con i dati della tua ditta (ragione sociale, logotipo, partita IVA, IBAN e quant’altro sei solito inserire nei preventivi, e analogamente un riquadro con i dati del cliente con ragione sociale, codice fiscale o partita IVA, eccetera, si può sempre fare in testa al corpo una unica tabella riquadrata con 2 colonne di tipo X (pacchetto tabularx) dal contenuto allineato a sinistra; poi puoi comporre la tabella con i dati del preventivo (una colonna X e una colonna r terminata con il simbolo dell’euro. Sotto ci metti i testi generali e e la firma.Praticamente la classe, richiama le cose che fai solitamente a mano, ma te le standardizza, in modo che tu non debba inventari ogni volta le cose da capo.
-
15 Aprile 2014 alle 4:59 #93983::
LBreda” post=93546Salve,
Esistono classi per (o adattabili per) fare preventivi? Finora mi sono abbastanza arrangiato a mano, ma i risultati lasciano molto a desiderare. Tabella a parte, è sempre un po’ problematico il posizionamento di dati e logo miei e del cliente.
Grazie,
—
Lorenzo BredaBenvenuto sul forum!
Aggiungo che occorre mettere a punto anche il lato “getione dati”.
Questo aspetto è fondamentale perché da esso dipende non solo l’efficienza con cui produci i preventivi, ma anche le potenzialità di crescita e modifica e adattamento.
Ho creato centinaia di preventivi con LaTeX, che per me si chiamano computi metrici esecutivi.
Ci sono qundi due punti di vista da tenere separati il più possibile:
* come il documento deve apparire
* quali dati devono essere gestitiPuoi dirci qualcosa di più su come è costruito un tuo preventivo?
I miei computi hanno per esempio tre sezioni:
* una prima sezione anagrafica per l’individuazione dell’oggetto dei lavori
* una sezione di voci prezzi/quantità/unità di misura/totale
* una sezione con una tabella di ripartizione delle speseNon vorrei insistere troppo, ma l’uso di un database dovrebbe essere sempre preso in considerazione in questi casi.
Saluti.
R.
-
15 Aprile 2014 alle 11:01 #93984::
OldClaudio” post=93548Già; credo che tu debba crearti una classe ad hoc; prova a vedere la guida tematica sulle classi, qui sopra nella sezione Documentazione.
Ricorda: il logo tuo va nella testatina, il logo del cliente, ammesso che in un preventivo ci voglia, va nel copro del messaggio.Ci proverò appena ho un po’ di tempo.
Se vuoi una intestazione che contenga due riquadri, uno con i dati della tua ditta (ragione sociale, logotipo, partita IVA, IBAN e quant’altro sei solito inserire nei preventivi, e analogamente un riquadro con i dati del cliente con ragione sociale, codice fiscale o partita IVA, eccetera, si può sempre fare in testa al corpo una unica tabella riquadrata con 2 colonne di tipo X (pacchetto tabularx) dal contenuto allineato a sinistra;
Ma una cosa del genere si può fare nella testatina?
robitex” post=93550
Benvenuto sul forum!Grazie! Qualche volta chiesi aiuto anche sul vecchio forum, ma secoli fa.
Aggiungo che occorre mettere a punto anche il lato “getione dati”.
Questo aspetto è fondamentale perché da esso dipende non solo l’efficienza con cui produci i preventivi, ma anche le potenzialità di crescita e modifica e adattamento.
Ho creato centinaia di preventivi con LaTeX, che per me si chiamano computi metrici esecutivi.Questo sarebbe molto interessante, sono decisamente a mio agio con i database. Ma come può essere implementata la cosa in LaTeX?
Puoi dirci qualcosa di più su come è costruito un tuo preventivo?
Intestazione con dati miei e del cliente, breve testo che riassume i requisiti del cliente sul lavoro, tabella del tipo “oggetto – costo”. A volte, in un documento analogo ma precedente al preventivo vero e proprio, le tabelle sono piú di una, per le diverse combinazioni di servizi tra i quali l’eventuale cliente con le idee poco chiare possa scegliere (ma potrei fare piú preventivi e sarebbe lo stesso).
Non vorrei insistere troppo, ma l’uso di un database dovrebbe essere sempre preso in considerazione in questi casi.
Sarebbe meraviglioso.
-
15 Aprile 2014 alle 11:30 #93985::
LBreda” post=93555
Già; credo che tu debba crearti una classe ad hoc; prova a vedere la guida tematica sulle classi, qui sopra nella sezione Documentazione.
Ricorda: il logo tuo va nella testatina, il logo del cliente, ammesso che in un preventivo ci voglia, va nel copro del messaggio.Ci proverò appena ho un po’ di tempo.
Se vuoi una intestazione che contenga due riquadri, uno con i dati della tua ditta (ragione sociale, logotipo, partita IVA, IBAN e quant’altro sei solito inserire nei preventivi, e analogamente un riquadro con i dati del cliente con ragione sociale, codice fiscale o partita IVA, eccetera, si può sempre fare in testa al corpo una unica tabella riquadrata con 2 colonne di tipo X (pacchetto tabularx) dal contenuto allineato a sinistra;
Ma una cosa del genere si può fare nella testatina?
robitex” post=93550
Benvenuto sul forum!Grazie! Qualche volta chiesi aiuto anche sul vecchio forum, ma secoli fa.
Aggiungo che occorre mettere a punto anche il lato “getione dati”.
Questo aspetto è fondamentale perché da esso dipende non solo l’efficienza con cui produci i preventivi, ma anche le potenzialità di crescita e modifica e adattamento.
Ho creato centinaia di preventivi con LaTeX, che per me si chiamano computi metrici esecutivi.Questo sarebbe molto interessante, sono decisamente a mio agio con i database. Ma come può essere implementata la cosa in LaTeX?
Puoi dirci qualcosa di più su come è costruito un tuo preventivo?
Intestazione con dati miei e del cliente, breve testo che riassume i requisiti del cliente sul lavoro, tabella del tipo “oggetto – costo”. A volte, in un documento analogo ma precedente al preventivo vero e proprio, le tabelle sono piú di una, per le diverse combinazioni di servizi tra i quali l’eventuale cliente con le idee poco chiare possa scegliere (ma potrei fare piú preventivi e sarebbe lo stesso).
Non vorrei insistere troppo, ma l’uso di un database dovrebbe essere sempre preso in considerazione in questi casi.
Sarebbe meraviglioso.
Potevi tranquillamente utilizzare le vecchie credenziali del sito del Sant’Anna.
Penso che per usare un db in LaTeX ci siano due strade:
1 – [modo esterno] creazione del sorgente in automatico, compilazione, report finale;
2 – [modo interno] creazione di un pacchetto per LuaLaTeX che si connette al db ed esegue le query.Uso preferibilmente la prima perché non è sempre facile connettersi da LuaTeX alle librerie, e forse si perde qualcosa.
Leggi per esempio questo post recente:
http://www.guitex.org/home/it/forum/5-tex-e-latex/93493-luatex-non-trova-il-modulo-luasqlsqlite3
ma esiste anche un post sul mio blog per PostgreSQL.
Saluti.
R.
-
16 Aprile 2014 alle 6:33 #93986::
robitex” post=93557
Potevi tranquillamente utilizzare le vecchie credenziali del sito del Sant’Anna.Uhm, non mi funzionarono, ma probabilmente sbaglio la password.
Penso che per usare un db in LaTeX ci siano due strade:
1 – [modo esterno] creazione del sorgente in automatico, compilazione, report finale;Sí, ovviamente, ma scrivere un programma che mi produca preventivi (e sarebbe carino producesse anche il PDF, ma mi sa che non ci sono librerie e tocchi cavarsela con qualche pipeline), al momento, mi pare un po’ come tentare di uccidere una mosca con un bazooka. Funziona, ma ne vale la pena?
2 – [modo interno] creazione di un pacchetto per LuaLaTeX che si connette al db ed esegue le query.
LuaLaTex è la prima volta che lo sento nominare. Potrebbe essere l’occasione per imparare qualcosa di nuovo, anche se a quanto mi dici è un bazooka che ogni tanto fa pure cilecca nel far fuori la mosca. Grazie per i link (per una cosa del genere preferirei SQLite, nonostante le noie di scalabilità nella progettazione del DB, che andare a modificare le strutture delle tabelle è una pena). Solo che non conosco il Lua, per quanto mi sembri molto facile da apprendere.
-
16 Aprile 2014 alle 6:59 #93987::
LBreda” post=93576
Potevi tranquillamente utilizzare le vecchie credenziali del sito del Sant’Anna.
Uhm, non mi funzionarono, ma probabilmente sbaglio la password.
Penso che per usare un db in LaTeX ci siano due strade:
1 – [modo esterno] creazione del sorgente in automatico, compilazione, report finale;Sí, ovviamente, ma scrivere un programma che mi produca preventivi (e sarebbe carino producesse anche il PDF, ma mi sa che non ci sono librerie e tocchi cavarsela con qualche pipeline), al momento, mi pare un po’ come tentare di uccidere una mosca con un bazooka. Funziona, ma ne vale la pena?
2 – [modo interno] creazione di un pacchetto per LuaLaTeX che si connette al db ed esegue le query.
LuaLaTex è la prima volta che lo sento nominare. Potrebbe essere l’occasione per imparare qualcosa di nuovo, anche se a quanto mi dici è un bazooka che ogni tanto fa pure cilecca nel far fuori la mosca. Grazie per i link (per una cosa del genere preferirei SQLite, nonostante le noie di scalabilità nella progettazione del DB, che andare a modificare le strutture delle tabelle è una pena). Solo che non conosco il Lua, per quanto mi sembri molto facile da apprendere.
Ciao,
nel modo 1 puoi usare il linguaggio che ritieni adatto: dal C a Ruby.
Per la questione ‘bazooka contro la mosca’ direi questo:
qualsiasi programma di gestione preventivi puoi vederlo come un bazooka contro la mosca.
Nel caso di cui stiamo ragionando, hai un vantaggio: l’applicazione la costruisci tu, il codice LaTeX lo crei tu ed è facilmente modificabile (nel senso che non si tratta di report da compilare in un binario ma di un file di testo).In questi giorni sto mettendo a punto un sistema basato su LaTeX per produrre documenti fiscali. Ho messo a punto la struttura del database ma non ho ancora deciso se passerò dal modo 1 o dal modo 2. Ed in effetti è abbastanza ininfluente: posso inserire i dati con mille client diversi e posso ralizzare i report con mille librerie diverse (purché ovvio compatibili con il database scelto).
Alla prossima.
R.
-
-
AutoreRisposte
- Devi essere connesso per rispondere a questo topic.