Le ricette di Konga: i web service

10 marzo 2015 at 09:39 60 commenti

By The National Archives UK (Making the Empire Christmas Pudding) [see page for license], via Wikimedia Commons

Spesso chi si occupa di informatica e di sviluppo software, quando finisce di combattere con hardware e software, si dedica alla cucina. Qualcuno potrebbe insinuare che si tratta di un inconscio “piano B” del programmatore: se il progetto software non ha successo, potrà sempre tentare miglior fortuna con una carriera come aiuto cuoco. In realtà le similitudini tra l’attività di programmazione e l’arte di cucinare sono molte: in entrambi i casi occorre creare un prodotto finale (il programma che deve essere pubblicato) partendo da una serie di materie prime (il linguaggio di programmazione con le sue librerie), spesso seguendo delle ricette (gli algoritmi o i “patterns” già utilizzati in passato).
Ci sono molte teorie sui motivi per cui spesso sviluppo software e cucina si accompagnano: sono ambedue attività creative, entrambe richiedono un certo livello di studio dell’argomento e sono attività che si prestano ad essere ottimizzate ed eseguite in parallelo (sono molti i piatti che richiedono di svolgere diverse attività contemporaneamente). Nel mio caso credo che cucinare sia una specie di “attività rifugio”, un surrogato dello sviluppo software. Nei momenti più difficili di un progetto, quando non riesco a vedere la fine e nulla funziona come dovrebbe, seguire una ricetta di cucina ed ottenere sempre (o quasi sempre) il risultato desiderato è una grande soddisfazione, e in modo indiretto mi dà speranza che anche il progetto software possa infine riuscire come il piatto che sto preparando.

Come avrete intuito dal titolo, in questo articolo voglio condividere con voi alcune ricette in cui l’ingrediente principale è Konga, in particolare la possibilità di Konga di interagire con  programmi esterni tramite i suoi “web service”.

In questo articolo utilizzeremo il termine “web service” per indicare genericamente la possibilità di interagire con Konga tramite il protocollo HTTP (in particolare utilizzando lo standard JSON-RPC), per una definizione più formale di che cosa si intende per web service rimandiamo alla definizione presente in wikipedia.

Utilizzando i web service di Konga è possibile collegarsi ai database, leggere, inserire, modificare e cancellare i dati avendo la certezza che Konga applicherà tutti i controlli di congruenza e gli eventuali aggiornamenti automatici dei dati definiti dalla “logica della gestione aziendale”. L’accesso via web service quindi è la soluzione più semplice quando si desidera sviluppare delle applicazioni esterne che devono condividere le informazioni della gestione aziendale.

È possibile abilitare i web service solo in Konga Pro, sia nella versione “stand-alone”, sia nella versione “server”. L’opzione per abilitare i web service è presente nella configurazione del server, alla voce “Servizio web”:

Configurazione del server - servizio web

Spuntando l’opzione “Avvia il server integrato” e lasciando selezionato il servizio di gestione delle richieste “JSON-RPC” si predispone Konga per rispondere alle richieste all’indirizzo:

http://INDIRIZZO_IP_DEL SERVER:8080/jsonrpc

(ovviamente l’INDIRIZZO_IP_DEL SERVER può essere sostituito dal NOME_DEL_SERVER quando quest’ultimo è stato registrato in un sistema per la risoluzione dei nomi – DNS).

Come si può vedere in figura, la porta di default è la 8080, ma nel caso in cui la porta 8080 sia già utilizzata da altri programmi è possibile impostarne una diversa.

Le richieste a Konga dovranno soddisfare la versione 2.0 dello standard denominato JSON-RPC, si tratta di un protocollo per eseguire delle chiamate a procedure remote (RPC) e queste richieste devono essere eseguite utilizzando il protocollo HTTP.

Per poter utilizzare con profitto i web service di Konga occorre sapere quali sono le richieste che possono essere fatte e conoscere i nomi delle tabelle e dei campi del database di Konga. Questa è la documentazione di riferimento delle chiamate JSON-RPC:
http://public.easybyte.it/docs/webservice/json_rpc.html.
In questa documentazione troverete la lista delle chiamate possibili, la descrizione della loro funzione ed i parametri di ingresso e di uscita. Come vedrete, le chiamate previste non sono molte – attualmente sono nove – comunque esse permettono di interagire con i dati di Konga in modo completo. Nel corso di questo articolo non analizzeremo tutte le chiamate, faremo invece qualche esempio pratico di utilizzo che, insieme alla documentazione di riferimento, dovrebbe essere sufficiente per permettere di utilizzare autonomamente tutte le chiamate previste.

Oltre a conoscere le chiamate possibili abbiamo detto che è anche necessario conoscere i nomi delle tabelle e i nomi dei campi del database che utilizza Konga, anche queste informazioni sono presenti nella documentazione tecnica che pubblichiamo on-line: http://public.easybyte.it/docs/datadict/tables.html.

Per loro natura i web service non sono legati ad uno specifico ambiente di sviluppo: possono ovviamente essere utilizzati da un’applicazione web, ma nulla osta al loro utilizzo dall’interno di un’applicazione sviluppata per l’ambiente “desktop” o, ad esempio, da una soluzione sviluppata con FileMaker. Per gli esempi di utilizzo che seguiranno utilizzeremo un ambiente di sviluppo che tutti utilizzate quotidianamente: il web browser, tenete bene a mente però che le stesse cose che faremo utilizzando il web browser possono essere fatte anche nella maggior parte dei linguaggi di programmazione e/o framework di sviluppo.

Il nostro “ambiente di sviluppo”
Per fare le richieste web service a Konga utilizzeremo Firefox insieme ad una estensione denominata “RESTClient”, grazie a questa estensione di Firefox saremo in grado di preparare le richieste HTTP, inviarle al Konga server, ricevere la risposta e analizzarne il suo contenuto.

RESTClient1

Come potete vedere nella figura qui sopra (cliccare per vedere l’immagine nella dimensione reale), per inviare una richiesta HTTP con il RESTClient è necessario:

1. il metodo HTTP che vogliamo utilizzare, per le richieste a Konga dovremo indicare il metodo POST

2. l’indirizzo a cui inviare la richiesta (URL), nel nostro caso invieremo la richiesta al Konga server che è stato attivato sullo stesso PC nel quale stiamo eseguendo Firefox, quindi l’indirizzo sarà

http://127.0.0.1:8080/jsonrpc/

3. il contenuto della richiesta (Body), per questa prima richiesta utilizzeremo il metodo list_databases per ottenere la lista dei database che possono essere aperti dal Konga server. La richiesta deve essere preparata secondo le regole del formato JSON:

{ "jsonrpc": "2.0", "method": "list_databases", "params": [ ] }

l’elemento “jsonrpc”: “2.0” specifica che la richiesta segue le regole della versione 2.0 di JSON-RPC, il parametro “method” contiene il nome della funzione che desideriamo eseguire (list_databases) e l’argomento “params” in questo caso è una lista vuota perché il metodo “list_databases” non prevede parametri.

Premendo SEND la richiesta viene inviata al server e se tutto è stato configurato correttamente il server risponderà immediatamente. Per visualizzare il contenuto della risposta clicchiamo nella sezione “Response Body”:

RESTClient2

Come potete vedere anche la risposta è in formato JSON, l’elemento che più ci interessa nella risposta è “error” che in questo caso è stato valorizzato a null, cioè nessun errore, nel caso in cui Konga ci risponda con un errore, l’elemento “error” conterrà uno o più codici di errore (“code”) e la corrispondente descrizione dell’errore, ad esempio se avessimo specificato un metodo inesistente avremmo ottenuto questa risposta:

RESTClient2.1

Quando non ci sono errori il server restituisce la lista dei database disponibili, in questo caso sul server sono presenti due database: Konga4Ever e Kongademo; per ogni database vengono restituiti alcuni attributi significativi che dovrebbero essere auto-esplicativi, tra questi il più interessante per noi è l’elemento “driver” che ci sarà indispensabile per eseguire la prossima chiamata: “open_database”, che esegue l’apertura del database.

Il metodo open_database

open_database(driver, dbname, username, password)

RESTClient3

Ora che conosciamo i nomi dei database ospitati dal Konga server, possiamo decidere di aprirne uno, ad esempio Kongademo. Per poter aprire un database dobbiamo conoscere oltre al suo nome anche il nome del driver del DB (SQLite o MySQL) e le credenziali per l’accesso, cioè il nome utente e la password. Come potete vedere nella figura il metodo open_database prevede proprio questi quattro parametri: driver (SQLite), nome del database (Kongademo), nome dell’utente (admin) e password (stringa vuota – ovvero nessuna password).

RESTClient4

La risposta alla chiamata open_database restituisce la cosiddetta “id di sessione”, cioè un identificatore che dovrò utilizzare come primo parametro per le chiamate successive, esso mi permette di non specificare ogni volta le credenziali per la connessione e abbinerà le mie future richieste ad una specifica sessione che rimane aperta sul server per almeno 15 minuti. In questo caso la nostra id di sessione è “e763191990b557f6beaecb6b61ec8957”.

La scadenza della sessione può essere configurata sul server (il valore di default è 15 minuti) e la scadenza verrà rinnovata ogni volta che eseguirò una chiamata al server, quindi la sessione scadrà dopo che non avrò eseguito nessuna chiamata al server per 15 minuti.

Un esempio di lettura: select_data

select_data(sid, tablename[, fieldnamelist, where_expr, order_by, order_desc, offset, limit])

RESTClient5

Uno dei metodi disponibili per la lettura dei dati di Konga è “select_data”, questo metodo è molto simile ad una query di tipo SELECT di un database SQL: oltre alla id di sessione questo metodo prevede di specificare un nome tabella e opzionalmente la lista dei nomi dei campi da restituire, una condizione di ricerca (where_expr), le modalità di ordinamento (order_by e order_desc) e di restituire solo un sottoinsieme dei risultati (offset e limit).

Nell’esempio in figura vogliamo leggere ragione sociale e indirizzo di un cliente di cui conosciamo il codice (C00100), quindi eseguiamo una select_data indicando “EB_ClientiFornitori” come nome tabella; “Codice”, “RagioneSociale” e “Indirizzo” come lista dei nomi dei campi e “Codice = ‘C00100′” come condizione di ricerca. Come si può intuire, la sintassi delle condizioni di ricerca è la stessa delle condizioni di ricerca di SQL.

Eseguendo la richiesta, questo è il risultato che viene restituito:

RESTClient6

Il risultato consiste di una lista di righe, dove la prima riga contiene i nomi dei campi richiesti, seguita da zero o più righe con i dati dei clienti-fornitori che soddisfano la condizione di ricerca. Nel caso in cui avessi cercato un codice inesistente, la chiamata sarebbe comunque andata a buon fine: sarebbe stata restituita la sola riga con i nomi dei campi e nessun dato a seguire.

Un esempio di scrittura: insert_record

insert_record(sid, tablename, code_azienda, num_esercizio, data)

In maniera molto simile alla lettura è anche possibile utilizzare i web service per inserire dei nuovi dati nel database di Konga. A scopo dimostrativo potete vedere qui sotto un esempio di inserimento di un ordine da cliente. Per evitare di complicare troppo l’esempio, ho indicato solo i campi strettamente obbligatori, ottenendo così un ordine cliente sicuramente incompleto per un uso “reale”, ad esempio ho omesso i prezzi nelle righe e quindi otterrò un ordine cliente con valore totale uguale a zero, ma in compenso posso mostrarvi un esempio decisamente più leggibile.

RESTClient7

Come già visto nella select_data i primi due parametri sono l’id della sessione e il nome della tabella, seguiti dal codice dell’azienda (“00000001”), dal codice dell’esercizio (“00000001”) e dai dati che compongono l’ordine cliente che vogliamo inserire. Il codice dell’azienda è necessario perché Konga può gestire più aziende nello stesso database e quindi dobbiamo specificare in quale azienda vogliamo inserire l’ordine. Il codice dell’esercizio è necessario quando la tabella oggetto della chiamata contiene dei dati che sono separati in base agli esercizi contabili, nel caso degli ordini da cliente non sarebbe obbligatorio e potremmo passare “null”, ma nulla osta a specificare un codice esercizio anche quando non è necessario e, così facendo, si evita di dimenticarsene nei casi in cui serve.

I dati dell’ordine da inserire sono composti da una serie di elementi con i nomi dei campi della testata abbinati ai rispettivi valori, quindi un elemento convenzionale denominato “@rows” che contiene la lista delle righe dell’ordine.

Nei dati specificati per la testata dell’ordine è bene notare una particolarità, si tratta del nome dei campi che iniziano con “code_”. Questi sono campi che non troverete documentati nella lista campi di Konga, troverete invece documentati i campi corrispondenti che iniziano con “ref_” al posto di “code_”. Se un nome campo inizia con “ref_” significa che si tratta di una id di una tabella collegata (foreign key in termini SQL), sostituendo la premessa “ref_” con “code_” si richiede al Konga server di decodificare – al posto nostro – i codici delle tabelle e trasformarli nelle corrispondenti id, in tal modo chi esegue la chiamata potrebbe essere facilitato. L’utilizzo dei campi “code_” è spesso un vantaggio perché un codice rimane costante tra un database e un altro (ad esempio dopo un ripristino di un back-up), mentre la corrispondente id potrebbe variare con il database. La scelta di specificare il codice o la id di una tabella collegata dipende spesso dal contesto dell’operazione che si sta eseguendo, in ogni caso Konga semplifica le cose accettando entrambi i valori.

Vorrei anche farvi notare questi due campi obbligatori: “EB_OrdiniClienti.code_Valuta” e “EB_OrdiniClienti.code_Azienda”. Il codice della valuta è sempre obbligatorio, nel dubbio specificate il valore “EUR” che normalmente corrisponde alla valuta di conto. Il campo “code_Azienda” non lo avevamo già indicato tra i paramentri della chiamata? Sì, ma Konga desidera che venga ribadito anche nei dati che vengono passati… ogni tanto è necessario accontentare i programmi senza porsi troppe domande.

Nelle due righe dell’ordine vengono specificati, a scopo esemplificativo, solo i campi obbligatori: Codice articolo, unità di misura e quantità.

Eseguendo la chiamata, otterremo una risposta simile a questa:

RESTClient8

L’elemento “id” sarà l’id dell’ordine nel database, mentre “code” sarà il numero interno che è stato assegnato dal Konga server all’ordine appena inserito: l’ordine da cliente numero 11.

Questo era l’ultimo esempio per questo articolo, gli argomenti tecnici come questo non sono semplici né da leggere, né da descrivere, ed è probabile che leggendo questo articolo nascano dei dubbi e delle domande su argomenti che non ho affrontato… come al solito siamo a disposizione per tutti i chiarimenti: scrivete nei commenti del blog oppure inviate un messaggio email a <supportosw@converge.it>.

Entry filed under: integrazione, Konga, web service. Tags: , , , , .

Konga versione 1.0.6 Konga versione 1.0.6.1

60 commenti Add your own

  • 1. Chiara  |  11 marzo 2015 alle 01:15

    Dubbi e domande tanti… Derivano esclusivamente dalla mia (auspico) momentanea incapacità di comprendere appieno quanto meravigliosamente raccontato… Konga è un prodotto fantastico… Ed ogni giorno mi insegna cose nuove… Affascinanti, divertenti, fondamentali … Come solo un succulento, nuovo modo di preparare la zuppa di pesce presentandola a tavola in un barattolo sa fare… Bravissimi.

    Rispondi
  • 2. Antonio  |  1 aprile 2015 alle 11:27

    Sto facendo delle prove ma non mi è chiaro come accedere per esempio al saldo di una scheda cliente o meglio ancora come ottenere le righe di un partitario cliente
    Grazie

    Rispondi
    • 3. Fabrizio Toso  |  1 aprile 2015 alle 12:08

      I dati contabili progressivi dei clienti sono memorizzati nella tabella EB_ProgressiviCliFor ed essa è collegata all’esercizio e al cliente-fornitore: il campo ref_Esercizio contiene l’id della tabella EB_Esercizi e il campo ref_ClienteFornitore contiene l’id della tabella EB_ClientiFornitori. Quindi per accedere a questi dati dovrò per prima cosa recuperare il campo id dell’esercizio che mi interessa, ad esempio se il codice dell’esercizio che mi interessa è il “00000001”, eseguirò una query di questo tipo:
      select_data(SESSION_ID, "EB_Esercizi", [ "id" ], "Codice = '00000001'")
      Ottenuta l’id dell’esercizio mi occorre l’id del cliente in esame, supponiamo di conoscere il codice del cliente – ad esempio C00100 – e quindi eseguiremo:
      select_data(SESSION_ID, "EB_ClientiFornitori", [ "id" ], "Codice = 'C00100'")
      Infine leggeremo la riga della tabella EB_ProgressiviCliFor:
      select_data(SESSION_ID, "EB_ProgressiviCliFor", [ "Saldo" ], "ref_ClienteFornitore = ID_CLIENTEFORNITORE AND ref_Esercizio = ID_ESERCIZIO")
      Ovviamente la sintassi sarà un po’ diversa: occorrerà sostituire ID_CLIENTEFORNITORE e ID_ESERCIZIO con dei valori variabili, e la modalità cambierà in base all’ambiente di sviluppo che si sta utilizzando.
      Per leggere le lista delle registrazioni di prima nota che interessano uno specifico cliente, la tabella da leggere sarà EB_RighePrimaNota (ed eventualmente anche EB_PrimaNota che contiene i dati della testata). Anche nel caso di EB_RighePrimaNota il collegamento con il cliente avviene tramite il campo ref_ClienteFornitore che conterrà l’id del cliente, quindi eseguendo una select_data sulle righe otterremo tutte le righe di prima nota che interessano il cliente – di tutti gli esercizi. Per eseguire una selezione di un solo esercizio contabile si dovrà coinvolgere anche la tabella EB_PrimaNota che contiene il campo ref_Esercizio. Il collegamento tra una riga di prima nota e la sua intestazione avviene tramite il campo ref_PrimaNota che – ora lo sappiamo – contiene l’id di una riga della tabella EB_PrimaNota.
      A questo punto entrerebbero in gioco delle query un po’ più complesse che utilizzando la sintassi SQL mettono in relazione le due tabelle EB_PrimaNota e EB_RighePrimaNota, ma non mi pare questa la sede per approfondire l’argomento.

      Rispondi
      • 4. Antonio  |  1 aprile 2015 alle 22:42

        Wow
        Molto piacevolmente sorpreso dalla celerità nella replica.
        Domani mattina provo di sicuro.
        Grazie mille.

  • 5. Lorenzo  |  13 gennaio 2016 alle 17:39

    Buonasera,
    come posso ottenere la giacenza conoscendo il Codice di un Articolo?

    Rispondi
    • 6. Fabrizio Toso  |  13 gennaio 2016 alle 17:59

      Per prima cosa è necessario recuperare l’id dell’articolo eseguendo una query simile a questa:

      SELECT EB_Articoli.id FROM EB_Articoli WHERE EB_Articoli.Codice = ‘CODICE’

      Quindi supponendo di avere già recuperato l’id dell’esercizio di cui ci interessa la giacenza, possiamo eseguire una query su EB_ProgressiviArticoli per ottenere la giacenza:

      SELECT EB_ProgressiviArticoli.Giacenza FROM EB_ProgressiviArticoli WHERE EB_ProgressiviArticoli.ref_Articolo = ID_ARTICOLO AND EB_ProgressiviArticoli.ref_Esercizio = ID_ESERCIZIO

      I progressivi degli articoli di magazzino sono legati anche al magazzino, quindi nel caso in cui esista più di un magazzino nella tabella magazzini sarebbe opportuno aggiungere anche un “AND EB_ProgressiviArticoli.ref_Magazzino = ID_MAGAZZINO”.

      Nel caso in cui la query sui progressivi ritorni un risultato vuoto, significa che l’articolo non è mai stato movimentato e quindi la giacenza è uguale a zero.

      Richieste simili possono essere anche eseguite cercando per codice esercizio o codice magazzino invece che per id, ma in tal caso occorrerà aggiungere anche dei criteri per la selezione dell’azienda, perché il codice – a differenza dell’id – potrebbe non essere univoco. Questo può capitare sia in situazioni di DB multi-aziendali, sia in situazioni mono-aziendali dove lo stesso codice è stato utilizzato per un articolo comune a tutte le aziende e per un articolo specifico di un’azienda (anche se questi casi sono effettivamente rari, ad esempio la codifica automatica degli articoli di Konga prevede sempre dei codici differenti tra gli articoli comuni per tutte le aziende e quelli che appartengono ad una specifica azienda).

      Rispondi
      • 7. Lorenzo  |  15 gennaio 2016 alle 14:18

        Grazie per la risposta così completa, ho testato e sono riuscito facilmente ad ottenere la giacenza!
        Se possibile può spiegarmi anche com’è gestita l’immagine (o immagini?) dell’articolo e come ottenerla/e? Nel DB è salvato solo il path per l’immagine o l’immagine vera e propria?

      • 8. Fabrizio Toso  |  15 gennaio 2016 alle 15:40

        La scelta se memorizzare le immagini nel database o in un filesystem esterno al database viene fatta dall’utente all’inizio della gestione impostando un’apposita preferenza nella “Configurazione del database->Avanzate”. Nel caso in cui si sia scelto di memorizzare le immagini nel database, queste vengono memorizzate come BLOB in EB_DatiBinari. Tra i campi di EB_DatiBinari si trova “val_Tipo” che indica qual è il tipo di dato binario memorizzato (allegato, immagine, etc…):

        http://public.easybyte.it/docs/datadict/choice_resources.html#choice-resources

        EB_DatiBinari è collegata all’articolo tramite i campi ref_Tabella e Riga. Il campo ref_Tabella indica, passando per EB_Tabelle, a quale tabella il dato è collegato e il campo Riga contiene l’id della riga della tabella, nel caso in esame l’id dell’articolo.

        Nel caso di immagini interne al database l’immagine si troverà nel campo “Contenuto”, altrimenti il campo “NomeAllegato” conterrà il path completo per raggiungere l’immagine esterna al database.

        Non credo che l’accesso a questo tipo di dati sia mai stato eseguito passando tramite i web service, in linea di massima dovrebbe funzionare, ma potrebbero anche esserci delle sorprese.

      • 9. Lorenzo  |  15 gennaio 2016 alle 15:42

        Ottimo, grazie nuovamente per la velocità nella risposta e la spiegazione esaustiva!

      • 10. Fabrizio Toso  |  17 marzo 2016 alle 18:07

        Un’altra richiesta frequente è quella di ottenere la giacenza di un singolo titolo di deposito.

        In questo caso è necessario ottenere l’id di EB_ProgressiviArticoli utilizzando la metodologia esposta nella precedente risposta:

        SELECT EB_ProgressiviArticoli.id FROM EB_ProgressiviArticoli WHERE EB_ProgressiviArticoli.ref_Articolo = ID_ARTICOLO AND EB_ProgressiviArticoli.ref_Esercizio = ID_ESERCIZIO

        Una volta ottenuta l’id di EB_ProgressiviArticoli occorre conoscere anche l’id corrispondente al titolo di deposito che mi interessa:

        SELECT EB_TitoliDeposito.id FROM EB_TitoliDeposito WHERE EB_TitoliDeposito.Codice = ‘CODICE_TITOLO_DEPOSITO’

        Quindi si potrà eseguire una query sulla tabella EB_GiacenzeTitDep per ottenere la giacenza del titolo di deposito:

        SELECT EB_GiacenzeTitDep.Giacenza FROM EB_GiacenzeTitDep WHERE EB_GiacenzeTitDep.ref_ProgressivoArticolo = ID_PROGRESSIVO_ARTICOLO AND EB_GiacenzeTitDep.ref_TitoloDeposito = ID_TITOLO_DEPOSITO

  • 11. Enzo Callegari  |  11 settembre 2016 alle 17:34

    Buon giorno,
    come si identificano i campi obbligatori per inserire un record?

    Rispondi
    • 12. Fabrizio Toso  |  11 settembre 2016 alle 17:40

      I campi obbligatori si possono vedere simulando un’esportazione dati della tabella in esame: al momento di selezionare la lista dei campi da esportare, quelli obbligatori sono evidenziati in grassetto. L’esportazione dei dati si può eseguire da Konga: menù Manutenzione->Esportazione dati

      Rispondi
      • 13. Enzo Callegari  |  11 settembre 2016 alle 18:29

        Grazie mille

  • 14. Enzo Callegari  |  11 settembre 2016 alle 19:19

    Stò testando le chiamate al webservice in nello specifico “select_data” ma non capisco come si devono comporre le join.
    Ad esempio come dovrebbe essere composto il json per eseguire la seguente query?

    SELECT EB_DocumentiFiscali.id, EB_TipologieDocumenti.tra_Descrizione FROM EB_DocumentiFiscali
    JOIN EB_TipologieDocumenti ON EB_TipologieDocumenti.id = EB_DocumentiFiscali.ref_Tipologia
    WHERE RagioneSociale = ‘PIPPO’ AND ref_Tipologia = 11

    Grazie

    Rispondi
    • 15. Fabrizio Toso  |  12 settembre 2016 alle 09:40

      Le join sono implicite e verranno risolte automaticamente lato server, basta utilizzare i nomi campo concatenati con il ‘.’ separatore. Ad esempio, nel caso in questione una richiesta di questo tipo torna i risultati voluti:

      { "jsonrpc": "2.0", "id" :1,
      "method": "select_data",
      "params": ["8364e5f6c189544f84208be3b69fc239",
      "EB_DocumentiFiscali", ["EB_DocumentiFiscali.id", "EB_DocumentiFiscali.ref_Tipologia.tra_Descrizione"] ,
      "EB_DocumentiFiscali.RagioneSociale = 'PIPPO' AND EB_DocumentiFiscali.ref_Tipologia = 11"
      ]
      }

      Rispondi
      • 16. Enzo Callegari  |  12 settembre 2016 alle 13:34

        Grazie

  • 17. Enzo Callegari  |  15 settembre 2016 alle 06:22

    Buon giorno,

    ho la necessità di disabilitare la Codifica automatica articoli.

    Io ho cercato su configurazione azienda ma la riga “Codifica automatica articoli” è disattivata…

    Come si disattiva questa funzione?

    Grazie
    Enzo

    Rispondi
    • 18. Fabrizio Toso  |  15 settembre 2016 alle 06:24

      Si disattiva dalla configurazione del database, perché gli articoli possono essere anche comuni a tutte le aziende

      Rispondi
      • 19. Enzo Callegari  |  15 settembre 2016 alle 06:31

        grazie

  • 20. Enzo Callegari  |  15 settembre 2016 alle 19:09

    Buona sera,

    stò tentando di comporre un json per fare una delete senza passare l’id.
    io passo questo:
    {“jsonrpc”:”2.0″,”id”:”0″,”method”:”delete_record”,”params”:[“d9f82887e8465024aef86587b060d158″,”EB_Articoli”,{“EB_Articoli.codice”:”NUOVO_CODICE”,”EB_Articoli.code_azienda”:”00000001″,”EB_Articoli.num_esercizio”:”00000001″}]}

    ma mi ritorna sempre:
    “code”: 2201,
    “message”: “Il risultato della query non ha più righe disponibili”

    dove sbaglio?

    Grazie
    Enzo

    Rispondi
  • 21. Enzo Callegari  |  15 settembre 2016 alle 19:22

    riposto il json perchè il precedente è stato troncato

    {
    “jsonrpc”: “2.0”,
    “id”: “0”,
    “method”: “delete_record”,
    “params”: [“d9f82887e8465024aef86587b060d158”, “EB_Articoli”, {
    “EB_Articoli.codice”: “NUOVO_CODICE”,
    “EB_Articoli.code_azienda”: “00000001”,
    “EB_Articoli.num_esercizio”: “00000001”
    }]
    }

    Rispondi
    • 22. Fabrizio Toso  |  16 settembre 2016 alle 07:42

      La funzione delete_record prevede solo un array di parametri, non deve essere indicato un array associativo:

      delete_record(sid, tablename[, id, code, code_azienda, num_esercizio])

      vedere: http://public.easybyte.it/docs/webservice/json_rpc.html#delete_record

      Quindi i parametri da passare sono di questo tipo:

      {
      "jsonrpc": "2.0",
      "id": "0",
      "method": "delete_record",
      "params": ["3eab1f4ec67a5201982d3ebb49b0abaa", "EB_Articoli", null, "NUOVO_CODICE", "00000001","00000001"]
      }

      Rispondi
      • 23. Enzo Callegari  |  16 settembre 2016 alle 09:29

        Grazie

  • 24. Enzo Callegari  |  18 settembre 2016 alle 19:27

    Salve,
    sto cercando di creare un preventivo con il json qui sotto.

    {
    “jsonrpc”: “2.0”,
    “id”: “0”,
    “method”: “insert_record”,
    “params”: [“65f357f4ff1e57b497fc8925942c0ca9”, “EB_Preventivi”, “00000001”, “00000001”, {
    “EB_Preventivi.code_Tipologia”: “08”,
    “EB_Preventivi.code_Azienda”: “00000001”,
    “EB_Preventivi.code_Valuta”: “EUR”,
    “EB_Preventivi.CodiceCliente”: “C01050”
    }]
    }

    Il preventivo si crea ma però non sono riuscito a far completare i campi passando il codice cliente.
    Ho provato anche a sostituire
    “EB_Preventivi.CodiceCliente”: “C01050”
    con
    “EB_Preventivi.ref_Cliente”: “1717” che l’id della riga ClientiFornitori
    ed anche con
    “EB_Preventivi.code_Cliente”: “C01050”
    ma in nessun modo si completano gli altri campi collegati al cliente, come RagioneSociale, indirizzo etc etc

    c’è qualcosa in particolare da impostare o da passare per ottenere la compilazione automatica?

    Grazie
    Enzo

    Rispondi
    • 25. Fabrizio Toso  |  18 settembre 2016 alle 19:58

      No, non è prevista la compilazione automatica: ogni preventivo ha i propri attributi di ragione sociale, indirizzo, etc, anche perché essi possono variare nel tempo… In questo caso è necessario eseguire una lettura del cliente e indicare i singoli campi nella “insert_record” del preventivo

      Rispondi
      • 26. Enzo Callegari  |  18 settembre 2016 alle 20:22

        Grazie

  • 27. Enzo Callegari  |  19 settembre 2016 alle 12:30

    Buon giorno,
    per i preventivi e i documenti fiscali alla sessione righe è possibile visualizzare il totale di ogni riga?

    Grazie
    Enzo

    Rispondi
    • 28. Fabrizio Toso  |  19 settembre 2016 alle 12:59

      Non è chiaro che cosa intende per “alla sessione righe”… parliamo della visualizzazione nel programma o della lettura dei dati via web service?

      Rispondi
      • 29. Enzo Callegari  |  19 settembre 2016 alle 13:03

        mi riferivo alla visualizzazione nel programma

      • 30. Fabrizio Toso  |  19 settembre 2016 alle 13:17

        Nella scheda in consultazione vi è un’apposita area sotto la griglia delle righe, dove vengono visualizzati dei dati aggiuntivi della riga selezionata, tra questi vi sono anche il totale lordo e il totale netto di riga.

      • 31. Enzo Callegari  |  19 settembre 2016 alle 13:36

        Si possono leggere anche via web service?

      • 32. Fabrizio Toso  |  19 settembre 2016 alle 13:43

        No, via web service si possono leggere solo i dati presenti nel database, quindi per le righe dei documenti fiscali: http://public.easybyte.it/docs/datadict/eb_righedocfiscali.html e per le righe dei preventivi: http://public.easybyte.it/docs/datadict/eb_righepreventivi.html

  • 33. Enzo Callegari  |  19 settembre 2016 alle 21:43

    Buona sera,
    sto utilizzando il web service per l’inserimento di un documento fiscale, il result ritorna ok e mi da id e num interno del documento creato. Non capiso però come mai Konga non mi visualizza il documento. Preciso che nel database nella tabella EB_DocumentiFiscali la riga del documento esiste ed esistono anche le righe contenute nella tabella EB_RigheDocFiscali.
    Questo è il JSON che passo:

    {
    “jsonrpc”:”2.0″,
    “id”:”0″,
    “method”:”insert_record”,
    “params”:[
    sid,
    “EB_DocumentiFiscali”,
    “00000001”,
    “00000001”,
    {
    “EB_DocumentiFiscali.code_Azienda”:”00000001″,
    “EB_DocumentiFiscali.code_Tipologia”:”01″,
    “EB_DocumentiFiscali.code_Valuta”:”EUR”,
    “EB_DocumentiFiscali.code_Cliente”:”C01050″,
    “EB_DocumentiFiscali.RagioneSociale”:”FIL SERRAMENTI SRL”,
    “EB_DocumentiFiscali.Indirizzo”:”VIA ZECCHINA, 21″,
    “EB_DocumentiFiscali.Localita”:”QUINTO DI TREVISO”,
    “EB_DocumentiFiscali.CAP”:”31055″,
    “EB_DocumentiFiscali.Provincia”:”TV”,
    “EB_DocumentiFiscali.PartitaIVA”:”00239940265″,
    “EB_DocumentiFiscali.DataDocumento”:”2016-09-19″,
    “EB_DocumentiFiscali.code_CausaleMagazzino”:”SCCL”,
    “EB_DocumentiFiscali.code_TitDepUscita”:”0101″,
    “EB_DocumentiFiscali.code_Esercizio”:”00000001″,
    “@rows”:[
    {
    “EB_RigheDocFiscali.code_Articolo”:”A 618 EU”,
    “EB_RigheDocFiscali.DescArticolo”:”GUARNIZIONE EPDM NERA 68X10″,
    “EB_RigheDocFiscali.code_RigheUnitaMisura”:”MT”,
    “EB_RigheDocFiscali.ValoreUnitario”:”6,484″,
    “EB_RigheDocFiscali.Sconto”:”20+10″,
    “EB_RigheDocFiscali.ValoreUnitarioNetto”:”4,668″,
    “EB_RigheDocFiscali.Quantita”:”100″,
    “EB_RigheDocFiscali.code_AliquotaIVA”:”22″,
    “EB_RigheDocFiscali.code_SottRicavo”:”20.01.05″
    }
    ]
    }
    ]
    }

    grazie
    Enzo

    Rispondi
    • 34. Fabrizio Toso  |  20 settembre 2016 alle 08:18

      I dati che vengono passati sembrano corretti. Potrebbe essere solo un problema di “refresh” della lista, oppure il fatto che ci siano più esercizi e/o più aziende nel database e la vista sia impostata sull’esercizio o azienda errati.
      Eseguendo una insert_record simile (vedere sotto) in un database creato con i dati di Esempio, il documento fiscale appare normalmente.

      {
      "jsonrpc":"2.0",
      "id":"0",
      "method":"insert_record",
      "params":[
      "26981246390e5a6594ffbcbe9ab40a0e",
      "EB_DocumentiFiscali",
      "00000001",
      "00000001",
      {
      "EB_DocumentiFiscali.code_Azienda":"00000001",
      "EB_DocumentiFiscali.code_Tipologia":"01",
      "EB_DocumentiFiscali.code_Valuta":"EUR",
      "EB_DocumentiFiscali.code_Cliente":"C00100",
      "EB_DocumentiFiscali.RagioneSociale":"FIL SERRAMENTI SRL",
      "EB_DocumentiFiscali.Indirizzo":"VIA ZECCHINA, 21",
      "EB_DocumentiFiscali.Localita":"QUINTO DI TREVISO",
      "EB_DocumentiFiscali.CAP":"31055",
      "EB_DocumentiFiscali.Provincia":"TV",
      "EB_DocumentiFiscali.PartitaIVA":"00239940265",
      "EB_DocumentiFiscali.DataDocumento":"2000-12-31",
      "EB_DocumentiFiscali.code_CausaleMagazzino":"SCCL",
      "EB_DocumentiFiscali.code_TitDepUscita":"0101",
      "EB_DocumentiFiscali.code_Esercizio":"00000001",
      "@rows":[
      {
      "EB_RigheDocFiscali.code_Articolo":"000001",
      "EB_RigheDocFiscali.DescArticolo":"GUARNIZIONE EPDM NERA 68X10",
      "EB_RigheDocFiscali.code_RigheUnitaMisura":"PZ",
      "EB_RigheDocFiscali.ValoreUnitario":"6,484",
      "EB_RigheDocFiscali.Sconto":"20+10",
      "EB_RigheDocFiscali.ValoreUnitarioNetto":"4,668",
      "EB_RigheDocFiscali.Quantita":"100",
      "EB_RigheDocFiscali.code_AliquotaIVA":"22",
      "EB_RigheDocFiscali.code_SottRicavo":"20.01.01"
      }
      ]
      }
      ]
      }

      Rispondi
      • 35. Enzo Callegari  |  20 settembre 2016 alle 09:59

        Buon giorno,
        effettivamente è stato un problema di “refresh”,
        dopo il riavvio del pc sembra funzionare tutto correttamente.

        grazie
        Enzo

  • 36. Enzo Callegari  |  23 settembre 2016 alle 09:16

    Buon giorno,
    sto cercando di capire come si abilita l’incremento automatico del NumeroProgressivo per preventivi ed ordini ma non trovo nessun parametro di configurazione a riguardo.
    Esiste un modo per farlo?

    grazie
    Enzo

    Rispondi
    • 37. Fabrizio Toso  |  23 settembre 2016 alle 17:24

      No, la conferma di un documento è un’operazione da eseguire direttamente sul Konga Client, non è prevista tra le operazioni dei web service. Quello che si può fare è di inserire un documento già confermato, ma in tal caso la numerazione progressiva dovrà essere gestita esternamente a Konga e nel caso in cui ci fossero degli automatismi lato client connessi alla conferma del documento, questi non verrebbero eseguiti. Dato che la conferma di un documento corrisponde ad una elaborazione lato server, è possibile eseguire l’operazione dall’esterno di Konga solo utilizzando direttamente le API di kongalib, ma non via web service.

      Rispondi
      • 38. Enzo Callegari  |  24 settembre 2016 alle 09:00

        Grazie
        Enzo

  • 39. Enzo Callegari  |  24 settembre 2016 alle 13:55

    Buon giorno,
    in quale campo viene salvato l’ultimo progressivo dei preventivi?

    Rispondi
    • 40. Fabrizio Toso  |  24 settembre 2016 alle 17:41

      Il numero progressivo è abbinato alla tipologia del documento. Il campo è “UltimoNumConfermato” della tabella “EB_RigheTipologieDocumenti” che è collegata alla tabella “EB_TipologieDocumenti” e varia al variare dell’esercizio (ovvero quando si apre un nuovo esercizio viene creata una nuova riga nella tabella “EB_RigheTipologieDocumenti” e la numerazione usualmente riparte da zero)

      Rispondi
      • 41. Enzo Callegari  |  24 settembre 2016 alle 20:13

        Grazie
        Enzo

  • 42. Enzo Callegari  |  24 settembre 2016 alle 20:21

    Buona sera,
    ho cercato nella documentazione materiale relativo ai preventivi ma non sono riuscito a trovare qualcosa in merito. In particolare mi interessa capire come vengono gestite le revisioni.
    Dove posso qualcosa che riguardi questo argomento?

    Grazie
    Enzo

    Rispondi
    • 43. Fabrizio Toso  |  25 settembre 2016 alle 06:36

      Nel manuale delle vendite si descrivono le revisioni dei preventivi:
      “Oltre ai pannelli occorre segnalare la presenza di due pulsanti specifici posti sulla Barra degli Strumenti: Conferma e Revisione. Il primo segnala la conferma del preventivo apponendo una vidimazione sulla Scheda, il secondo duplica il Preventivo assegnando una numerazione specifica affinché possa essere modificato; gli stati di revisione consentono di conservare la serie storica degli interventi apportati al Preventivo.”
      Si intende dire che una volta confermato il preventivo, viene assegnato il numero progressivo definitivo, quindi per ogni revisione successiva il numero progressivo rimane inalterato e varia solo il numero di revisione. In linea di massima un nuovo numero progressivo verrà assegnato ad un nuovo preventivo, che non è la modifica di un preventivo già inserito e confermato.

      Rispondi
      • 44. Enzo Callegari  |  25 settembre 2016 alle 09:52

        Grazie,
        se pur duplicando l’intero preventivo in ogni sua parte, è possibile gestire le revisioni con il web service?

        Buona Domenica
        Enzo

      • 45. Fabrizio Toso  |  25 settembre 2016 alle 10:39

        Come per i documenti confermati, si tratta di una gestione da fare esternamente: nel caso dei preventivi, per conoscere il numero della prossima revisione, sarà necessario eseguire una query per numero progressivo, dei soli preventivi con stato diverso da “inserito”, ordinata per revisione e ottenere così il numero dell’ultima revisione per un dato numero progressivo e quindi poter poi inserire un preventivo con la revisione successiva all’ultima.

      • 46. Enzo Callegari  |  25 settembre 2016 alle 11:30

        Grazie
        per la cortesia, la velocità e la chiarezza delle sue risposte

        Saluti
        Enzo

  • 47. Enzo Callegari  |  10 novembre 2016 alle 16:26

    Buona sera,
    cerco un aiuto perché non riesco a creare un json per fare una select con il group by.

    Grazie

    Rispondi
    • 48. Fabrizio Toso  |  10 novembre 2016 alle 22:22

      Non è possibile utilizzare il “group by” via web service: occorre ottenere i dati dettagliati e poi elaborarli esternamente.

      Rispondi
  • 49. Enzo Callegari  |  12 novembre 2016 alle 09:42

    Grazie

    Rispondi
  • 50. Enzo Callegari  |  16 novembre 2016 alle 17:46

    Buona sera,
    cerco un aiuto perché non riesco a creare un json per fare un Update di una riga.
    Vi allego un esempio di quello che stò provando senza risultati….

    {“jsonrpc”:”2.0″,”id”:”0″,”method”:”update_record”,”params”:[“6367cae5fc4850ee85b54469a86f62ce”,”EB_RighePreventivi”,”196″,{“EB_RighePreventivi.Quantita”:”125″}]}

    preciso che 196 è l’id della riga che voglio modificare

    grazie
    Enzo

    Rispondi
    • 51. Fabrizio Toso  |  16 novembre 2016 alle 18:09

      Credo che il problema sia il fatto di cercare di accedere direttamente alle righe dei preventivi attraverso la funzione update_record: le funzioni get_record, insert_record e update_record operano sempre sull’intero preventivo (quindi EB_Preventivi), la business logic del server prevede che si sottoponga la registrazione/modifica in una richiesta unica. Una insert_record() di EB_Preventivi prevede la lista delle righe nell’elemento “@rows”, come nell’esempio citato in questo articolo nel caso dell’ordine e anche l’update_record prevede che vengano inviati sia i dati della testata, sia i dati delle righe… Quindi il modo corretto di utilizzare update_record è di leggere il preventivo da modificare attraverso una get_record, modificare una o più informazioni (testata e/o righe) e quindi passare i dati del preventivo alla update_record (della tabella EB_Preventivi).

      Rispondi
      • 52. Enzo Callegari  |  16 novembre 2016 alle 18:35

        Grazie

      • 53. Enzo Callegari  |  19 novembre 2016 alle 16:49

        Buona sera,

        ho fatto altri test con la funzione update_record ma non sono riuscito a trovare un riscontro positivo.
        Per semplificare la cosa ho provato a cambiare la descrizione di un articolo con un questo json:

        {
        “jsonrpc”: “2.0”,
        “id”: “0”,
        “method”: “update_record”,
        “params”: [“844c67e6dc5e56c4aa4020d2876d9431”, “EB_Articoli”, “33624”, {
        “EB_Articoli.tra_Descrizione”: “aaaaa”
        }]
        }

        La funzione ritorna questo:
        {
        “result”: null,
        “jsonrpc”: “2.0”,
        “error”: null,
        “id”: 0
        }

        ed il record non è stato modificato.

        Per cortesia potrebbe farmi un esempio di come dovrebbe essere composto il json per eseguire questa operazione?

        Grazie
        Enzo

      • 54. Fabrizio Toso  |  19 novembre 2016 alle 17:28

        I parametri della chiamata non sono corretti, nella documentazione tecnica (http://public.easybyte.it/docs/webservice/json_rpc.html#update_record) si dovrebbe evincere che è necessario passare 7 parametri: sid, tablename, id, code, code_azienda, num_esercizio, data — anche se le parentesi quadre indicano dei parametri opzionali, nel momento in cui si passa “data” e i parametri sono una lista, occorre citare tutti quelli intermedi.
        Ad esempio, per aggiornare l’articolo con id = 1:


        {"jsonrpc":"2.0",
        "method":"update_record",
        "params":["2c39a2d58c055edfb9ee3c51e6edbde7", "EB_Articoli", 1, null, null, null, { " EB_Articoli.tra_Descrizione": "iPhone 7 Silver" }],
        "id":1
        }

      • 55. Enzo Callegari  |  19 novembre 2016 alle 19:35

        Non avevo capito il senso di opzionale.
        Ora con i Null è tutto ok
        Grazie mille per la sua disponibilità

        Buona serata e buona Domenica
        Enzo

  • 56. Enzo Callegari  |  23 novembre 2016 alle 15:10

    Buona sera sign. Toso,
    ho un problema con il ws quando leggo la tabella EB_ClientiFornitori.

    Utilizzando le funzione “get_record” oppure “select_data” il campo “ref_BancaAzienda” torna sempre “null” anche se entrando nella scheda cliente da Konga il campo è valorizzato.

    Come posso recuperare questa informazione?

    Vi allego le prove che ho fatto

    Grazie
    Enzo

    get_record

    {
    “result”: {
    “EB_ClientiFornitori.val_AllegatiIVA”: 1,
    “EB_ClientiFornitori.RifAggiuntivo2”: “”,
    “EB_ClientiFornitori.SpeseImballo”: 0,
    “EB_ClientiFornitori.CAP”: “31038”,
    “EB_ClientiFornitori.ref_AliquotaIVA”: null,
    “EB_ClientiFornitori.id”: 2027,
    “EB_ClientiFornitori.val_AddebitoImballo”: 0,
    “EB_ClientiFornitori.RiferimentoInterno”: “20+10”,
    “EB_ClientiFornitori.val_EsclusoOpIVARil”: 0,
    “EB_ClientiFornitori.DataDichIntento”: “0000-00-00”,
    “@modified”: true,
    “EB_ClientiFornitori.Note”: “”,
    “EB_ClientiFornitori.ref_AIDichIntento”: null,
    “EB_ClientiFornitori.Nome”: “”,
    “EB_ClientiFornitori.NumeroDichIntentoDich”:0,
    “EB_ClientiFornitori.ref_Valuta”: 1,
    “EB_ClientiFornitori.val_SoggettoPrivato”: 0,
    “EB_ClientiFornitori.Riferimento”: “”,
    “EB_ClientiFornitori.val_ModalitaTrasporto”: 0,
    “EB_ClientiFornitori.ParolaChiave”: “”,
    “EB_ClientiFornitori.ref_CondizioneConsegna”:2,
    “EB_ClientiFornitori.ref_Vettore”: null,
    “EB_ClientiFornitori.ref_BancaAzienda”: null,
    “EB_ClientiFornitori.Provincia”: “TV”,
    “EB_ClientiFornitori.ref_Azienda”: null,
    “EB_ClientiFornitori.ProtocolloDichIntento”: “”,
    “EB_ClientiFornitori.CodiceFiscale”: “00637080268”,
    “EB_ClientiFornitori.ref_SchedContCliente”: null,
    “EB_ClientiFornitori.Telefono”: “e fax 0422-959795”,
    “EB_ClientiFornitori.EBMagic”: 1214398284950116096,
    “@num_docs”: 0,
    “EB_ClientiFornitori.flags”: 0,
    “@events”: [],
    “@has_ord_da_evadere”: false,
    “EB_ClientiFornitori.val_Nazione”: 107,
    “EB_ClientiFornitori.val_Sesso”: 0,
    “EB_ClientiFornitori.Fax”: “0422959795”,
    “EB_ClientiFornitori.Cognome”: “”,
    “EB_ClientiFornitori.IndirizzoEmail”: “info@paesanaserramentitreviso.it”,
    “EB_ClientiFornitori.val_ModalitaInvio”: 0,
    “EB_ClientiFornitori.val_PersonaFisica”: 1,
    “EB_ClientiFornitori.ref_UtenteCreazione”: 1,
    “EB_ClientiFornitori.NoteVettore”: “”,
    “EB_ClientiFornitori.Indirizzo”: “VIA LOMBARDIA, 7 Z.ART. – PADERNELLO”,
    “EB_ClientiFornitori.val_AddebitoSpese”: 1,
    “EB_ClientiFornitori.val_AbilitaSitoInternet”: 0,
    “EB_ClientiFornitori.ref_UtenteModifica”: 1,
    “EB_ClientiFornitori.TSCreazione”: “2016-06-01 11:09:20”,
    “EB_ClientiFornitori.CodStatoEstero”: “”,
    “EB_ClientiFornitori.SitoWeb”: “”,
    “EB_ClientiFornitori.ref_Zona”: 14,
    “EB_ClientiFornitori.Localita”: “PAESE”,
    “EB_ClientiFornitori.DataNascita”: “0000-00-00”,
    “EB_ClientiFornitori.val_DichIntento”: 0,
    “EB_ClientiFornitori.ref_Sconto”: null,
    “EB_ClientiFornitori.val_CodiceISO”: 12,
    “EB_ClientiFornitori.ref_Listino”: null,
    “EB_ClientiFornitori.val_NoleggioLeasing”: 0,
    “EB_ClientiFornitori.ComuneNascita”: “”,
    “EB_ClientiFornitori.Tipo”: 1,
    “EB_ClientiFornitori.CodiceAlternativo”: “”,
    “@EB_ProgressiviFidelity”: [],
    “EB_ClientiFornitori.ControlloIBAN”: “”,
    “EB_ClientiFornitori.ref_GruppoClienteFornitore”:8,
    “EB_ClientiFornitori.ref_Banca”: 13,
    “EB_ClientiFornitori.CIN”: “L”,
    “EB_ClientiFornitori.val_AbilitaRID”: 0,
    “EB_ClientiFornitori.SottRiepilogativo”: 1,
    “EB_ClientiFornitori.ref_Agente”: null,
    “EB_ClientiFornitori.ref_ClienteFornitore”: null,
    “EB_ClientiFornitori.TSModifica”: “2016-06-01 11:09:20”,
    “EB_ClientiFornitori.CodStatoEsteroNascita”: null,
    “EB_ClientiFornitori.ref_CondizionePagamento”:49,
    “EB_ClientiFornitori.val_TipoQuadroOpIVA”: 0,
    “EB_ClientiFornitori.val_RaggruppamentoDdT”:1,
    “EB_ClientiFornitori.OraModificaOLink”: “0000-00-00”,
    “@EB_CarteFidelity”: [],
    “EB_ClientiFornitori.ContoCorrente”: “007000063319”,
    “EB_ClientiFornitori.CodUnivocoUfficio”: “”,
    “EB_ClientiFornitori.PartitaIVA”: “00637080268”,
    “EB_ClientiFornitori.Titolo”: null,
    “EB_ClientiFornitori.SpeseTrasporto”: 0,
    “EB_ClientiFornitori.ProvinciaNascita”: “”,
    “EB_ClientiFornitori.val_Percipiente”: 0,
    “EB_ClientiFornitori.DataModificaOLink”: “0000-00-00”,
    “EB_ClientiFornitori.val_Regione”: 20,
    “EB_ClientiFornitori.uuid”: “C97CE163-A779-51C3-A509-D9272B980947”,
    “EB_ClientiFornitori.Iban”: “”,
    “EB_ClientiFornitori.val_TipoVeicoloNoleggio”:0,
    “EB_ClientiFornitori.RagioneSociale”: “PAESANA SERRAMENTI DE MARCHI & MURER SNC”,
    “@has_notes”: false,
    “EB_ClientiFornitori.Codice”: “C0693”,
    “EB_ClientiFornitori.RifAggiuntivo1”: “”,
    “EB_ClientiFornitori.RifAggiuntivo3”: “”,
    “EB_ClientiFornitori.NumeroDichIntentoAss”: 0
    },
    “jsonrpc”: “2.0”,
    “error”: null,
    “id”: 0
    }

    select_data

    {
    “jsonrpc”: “2.0”,
    “id”: “0”,
    “method”: “select_data”,
    “params”: [“ea65f4a312a45520be4cdb396440fe28”, “EB_ClientiFornitori”, [“EB_ClientiFornitori.Codice”, “EB_ClientiFornitori.RagioneSociale”, “EB_ClientiFornitori.code_GruppoClienteFornitore”, “EB_ClientiFornitori.code_CondizionePagamento”, “EB_ClientiFornitori.ref_BancaAzienda”, “EB_ClientiFornitori.ref_Banca”], “EB_ClientiFornitori.Codice = ‘C0693′”]
    }

    {
    “result”: [[“EB_ClientiFornitori.Codice”, “EB_ClientiFornitori.RagioneSociale”, “EB_ClientiFornitori.code_GruppoClienteFornitore”, “EB_ClientiFornitori.code_CondizionePagamento”, “EB_ClientiFornitori.ref_BancaAzienda”, “EB_ClientiFornitori.ref_Banca”], [“C0693”, “PAESANA SERRAMENTI DE MARCHI & MURER SNC”, “003”, “RB30”, null, 13]],
    “jsonrpc”: “2.0”,
    “error”: null,
    “id”: 0
    }

    Rispondi
    • 57. Fabrizio Toso  |  23 novembre 2016 alle 18:06

      Il motivo è che il dato della banca dell’azienda si trova nella tabella “EB_DatiCliForAzienda” perché nel caso di database multi-aziendale ogni azienda potrebbe avere una banca differente abbinata al cliente (il campo presente nell’anagrafica del cliente è un campo “legacy” che attualmente non è utilizzato). Sarà quindi necessario eseguire una select_data aggiuntiva per ottenere il campo “EB_DatiCliForAzienda.ref_BancaAzienda” selezionando la riga in base a EB_DatiCliForAzienda.ref_ClienteFornitore e EB_DatiCliForAzienda.ref_Azienda

      Rispondi
      • 58. Enzo Callegari  |  23 novembre 2016 alle 23:46

        Ok, tutto chiaro, logico ed ovviamente funzionante !!

        grazie infinite
        Enzo

  • 59. Enzo Callegari  |  3 dicembre 2016 alle 11:26

    Buon giorno sig. Toso

    chiedo il suo aiuto per risolvere un problema che ho inserendo i dati con il ws.o Nello specifico si verica questo:

    I dati inseriti con il ws ( preventivi e ordini ) vengono visualizzati correttamente dalla postazione principale di Konga mentre non vengono visualizzati dai client. Per cortesia mi può aiutare a capire cosa stò sbagliando?

    grazie
    Enzo Callegari

    Rispondi
    • 60. Fabrizio Toso  |  3 dicembre 2016 alle 11:34

      Non vedo motivi di sorta per un problema di questo tipo. Le uniche spiegazioni sono quelle più ovvie: il client è connesso ad un server o database diverso, oppure è solo un problema di “refresh” della lista, in tal caso basterebbe cambiare il comando e poi ritornare sul comando preventivi o ordini per vedere la lista aggiornata.

      Rispondi

Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

Trackback this post  |  Subscribe to the comments via RSS Feed


Archivi

Seguici su Facebook


%d blogger cliccano Mi Piace per questo: