Fatturazione elettronica B2B: programmeli - parsade

di il
20 risposte

20 Risposte - Pagina 2

  • Re: Fatturazione elettronica B2B: programmeli - parsade

    amorosik ha scritto:


    +m2+ ha scritto:



    se può interessare a qualcuno, nel qual caso lo metto dentro xml2pdf.

    Stai scherzando vero?
    Certo che ci interessa e pure molto, siamo qua tutti con gli occhi di fuori per vedere "..e oggi cosa fa.."
    Il problema e' che con la divisione del 3d iniziale in tanti filoncini, non si riesce a seguirti
    A mio avviso sarebbero preferibili degli eseguibili separati, ognuno col suo compito specifico
    Infilare tutto dentro xml2pdf lo snatura e rende piu' complesso il suo utilizzo
    C'è gia, anche se "nascosto" (devo avere voglia di completarlo), si chiama parsade (è il porting di uno dei primi progetti, menzionato nel thread dei programmi).

    Riguardo agli eseguibili separati, assolutamente NO, perchè mi richiede un tempo enorme portare avanti indietro i vari pezzi di libreria.
    Ci sono un sacco di funzioni comuni, già "staccare" la form mi ha richiesto un mesetto di lavoro.
    D'altronde essendo lavoro non pagato, mentre la form un minimo di mercato ce l'ha, la risposta è inevitabile.


    ---
    Bon, detto questo, farei stilare la uissssss list.
  • Re: Fatturazione elettronica B2B: programmeli - parsade

    Capisco benissimo, non era una richiesta di cambiamento ma solo l'esternazione di come per me sarebbe stato preferibile
    Ma gia' cosi' e' tutto piu' che sfruttabile e soprattutto e' tutto utilissimo
    Comprendo bene pure il discorso gui (qualche scheo)/riga comando (niente schei)
    Capisco e contemporaneamente mi spiace un po' perche' dal mio punto di vista le funzioni via gui non riesco ad usarle

    My whishes:
    - riga comandi aggiornata a tutte le belle cose che c'ha la versione gui
    - xml postati, interpetati e schiaffati su formato strutturato (mdb, firebird, csv, a suo piacimento)
    - xml ricevuti, interpetati e schiaffati su formato strutturato (mdb, firebird, csv, facci un po' lei)
    - xml notifiche, interpetati e sparati su formato strutturato (mdb, firebird, csv, quel che vuoi)
  • Re: Fatturazione elettronica B2B: programmeli - parsade

    amorosik ha scritto:


    Capisco benissimo, non era una richiesta di cambiamento ma solo l'esternazione di come per me sarebbe stato preferibile
    Ma gia' cosi' e' tutto piu' che sfruttabile e soprattutto e' tutto utilissimo
    Comprendo bene pure il discorso gui (qualche scheo)/riga comando (niente schei)
    Capisco e contemporaneamente mi spiace un po' perche' dal mio punto di vista le funzioni via gui non riesco ad usarle
    Ma in effetti non le uso neppure io, sono "esposte" nella prima tab.
    In realtà il mio programmino usa le altre due (+ tante altre cose)
    My whishes:
    - riga comandi aggiornata a tutte le belle cose che c'ha la versione gui
    non difficile
    - xml postati, interpetati e schiaffati su formato strutturato (mdb, firebird, csv, a suo piacimento)
    lo fa già, dove credi vengano salvati i dati? Sono Absolute DB (o mysql per il programmino)
    - xml ricevuti, interpetati e schiaffati su formato strutturato (mdb, firebird, csv, facci un po' lei)
    - xml notifiche, interpetati e sparati su formato strutturato (mdb, firebird, csv, quel che vuoi)
    Servirebbe il porting della form FELIO, che ha come dipendenza la DOCUMENTI, che ne ha una ventina, tra cui globals.pas.

    Prima o poi, non è difficile, è solo... tedioso.

    ---
    Riassumendo: xml2pdf può scrivere i dati (e in generale è così che lo uso) su un database mysql (mariadb per la precisione), in (a memoria) circa 5 tabelle.
    Dal momento che non tutti usano mysql, e soprattutto posso farlo portabile (mariadb), ma è comunque una rottura, xml2pdf standalone usa un database "simil" sqllite, del mondo delphi.
    Quindi i dati ci sono già, esportati, belli da leggere (d'altronde fastreport su cosa credi che lavori?).

    Le versioni precedenti avevano un fintomysql (di cui sono particolarmente fiero), ma senza interrogazioni SQL, quindi avrei dovuto scrivere due programmi troppo diversi.
    ---
    Bene, chi vuole può quindi benissimo prendere i dati direttamente dal db.
    Per chi non è un delfaro si possono valutare altre soluzioni
    - la più veloce, per me, sarebbe una sorta di json dei poveri, qualcosa del tipo
    nomecampo1=valore1
    nomecampo2=valore2
    (...)

    che però richiederebbe una sorta di parser (anche se banale).

    - poi c'è l'alternativa mdb, cioè far scrivere su un mdb (2000) i dati delle tabelle.
    a quel punto i microsoffari possono leggerli per i zzi loro.
    questo richiede però che mi venga la voglia di fare il generatore di tabelle mdb, in sostanza legge il formato mysql e crea i campi mdb.
    esistono strumenti automatizzati, ma ovviamente non li uso e, soprattutto, dovrei rilanciarli alle modifiche del database mysql (fatica immane).

    -varie ed eventuali

    PS non uso firebird da un 15 anni almeno, spiacente.
  • Re: Fatturazione elettronica B2B: programmeli - parsade

    Proposta indecente(forse): visto che ci sono per delphi e VB ottimi driver (Activex dll, odbc, ecc) SQLITE, perchè non fare il DB in sqlite?

    xml2pdf è meglio di Beautiful

    +m2+ ha scritto:


    amorosik ha scritto:


    Capisco benissimo, non era una richiesta di cambiamento ma solo l'esternazione di come per me sarebbe stato preferibile
    Ma gia' cosi' e' tutto piu' che sfruttabile e soprattutto e' tutto utilissimo
    Comprendo bene pure il discorso gui (qualche scheo)/riga comando (niente schei)
    Capisco e contemporaneamente mi spiace un po' perche' dal mio punto di vista le funzioni via gui non riesco ad usarle
    Ma in effetti non le uso neppure io, sono "esposte" nella prima tab.
    In realtà il mio programmino usa le altre due (+ tante altre cose)
    My whishes:
    - riga comandi aggiornata a tutte le belle cose che c'ha la versione gui
    non difficile
    - xml postati, interpetati e schiaffati su formato strutturato (mdb, firebird, csv, a suo piacimento)
    lo fa già, dove credi vengano salvati i dati? Sono Absolute DB (o mysql per il programmino)
    - xml ricevuti, interpetati e schiaffati su formato strutturato (mdb, firebird, csv, facci un po' lei)
    - xml notifiche, interpetati e sparati su formato strutturato (mdb, firebird, csv, quel che vuoi)
    Servirebbe il porting della form FELIO, che ha come dipendenza la DOCUMENTI, che ne ha una ventina, tra cui globals.pas.

    Prima o poi, non è difficile, è solo... tedioso.

    ---
    Riassumendo: xml2pdf può scrivere i dati (e in generale è così che lo uso) su un database mysql (mariadb per la precisione), in (a memoria) circa 5 tabelle.
    Dal momento che non tutti usano mysql, e soprattutto posso farlo portabile (mariadb), ma è comunque una rottura, xml2pdf standalone usa un database "simil" sqllite, del mondo delphi.
    Quindi i dati ci sono già, esportati, belli da leggere (d'altronde fastreport su cosa credi che lavori?).

    Le versioni precedenti avevano un fintomysql (di cui sono particolarmente fiero), ma senza interrogazioni SQL, quindi avrei dovuto scrivere due programmi troppo diversi.
    ---
    Bene, chi vuole può quindi benissimo prendere i dati direttamente dal db.
    Per chi non è un delfaro si possono valutare altre soluzioni
    - la più veloce, per me, sarebbe una sorta di json dei poveri, qualcosa del tipo
    nomecampo1=valore1
    nomecampo2=valore2
    (...)

    che però richiederebbe una sorta di parser (anche se banale).

    - poi c'è l'alternativa mdb, cioè far scrivere su un mdb (2000) i dati delle tabelle.
    a quel punto i microsoffari possono leggerli per i zzi loro.
    questo richiede però che mi venga la voglia di fare il generatore di tabelle mdb, in sostanza legge il formato mysql e crea i campi mdb.
    esistono strumenti automatizzati, ma ovviamente non li uso e, soprattutto, dovrei rilanciarli alle modifiche del database mysql (fatica immane).

    -varie ed eventuali

    PS non uso firebird da un 15 anni almeno, spiacente.
  • Re: Fatturazione elettronica B2B: programmeli - parsade

    webgaldom ha scritto:


    Proposta indecente(forse): visto che ci sono per delphi e VB ottimi driver (Activex dll, odbc, ecc) SQLITE, perchè non fare il DB in sqlite?
    perchè francamente non lo uso.
    e, soprattutto, non credo sia molto "adatto" per access (e i microsoffari in generale)
  • Re: Fatturazione elettronica B2B: programmeli - parsade

    Se tu facessi il db in MDB, sarebbe troppa grazia per tutti, a parte i microsoffari.
    cmq, l'MDB andrebbe bene anche a me, visto che il tuo prog è per windows.

    +m2+ ha scritto:


    webgaldom ha scritto:


    Proposta indecente(forse): visto che ci sono per delphi e VB ottimi driver (Activex dll, odbc, ecc) SQLITE, perchè non fare il DB in sqlite?
    perchè francamente non lo uso.
    e, soprattutto, non credo sia molto "adatto" per access (e i microsoffari in generale)
Devi accedere o registrarti per scrivere nel forum
20 risposte