![By The National Archives UK (Making the Empire Christmas Pudding) [see page for license], via Wikimedia Commons](https://kongaerp.files.wordpress.com/2014/11/making_the_empire_christmas_pudding.jpg "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”:
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/current/technical/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/current/technical/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.
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”:
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:
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)
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).
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])
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:
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.
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:
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>.
Konga: contabilità e gestione aziendale 
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.
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
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.
Wow
Molto piacevolmente sorpreso dalla celerità nella replica.
Domani mattina provo di sicuro.
Grazie mille.
Buonasera,
come posso ottenere la giacenza conoscendo il Codice di un Articolo?
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).
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?
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.
Ottimo, grazie nuovamente per la velocità nella risposta e la spiegazione esaustiva!
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
Buon giorno,
come si identificano i campi obbligatori per inserire un record?
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
Grazie mille
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
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"
]
}
Grazie
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
Si disattiva dalla configurazione del database, perché gli articoli possono essere anche comuni a tutte le aziende
grazie
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
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”
}]
}
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"]
}
Grazie
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
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
Grazie
Buon giorno,
per i preventivi e i documenti fiscali alla sessione righe è possibile visualizzare il totale di ogni riga?
Grazie
Enzo
Non è chiaro che cosa intende per “alla sessione righe”… parliamo della visualizzazione nel programma o della lettura dei dati via web service?
mi riferivo alla visualizzazione nel programma
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.
Si possono leggere anche via web service?
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
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
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"
}
]
}
]
}
Buon giorno,
effettivamente è stato un problema di “refresh”,
dopo il riavvio del pc sembra funzionare tutto correttamente.
grazie
Enzo
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
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.
Grazie
Enzo
Buon giorno,
in quale campo viene salvato l’ultimo progressivo dei preventivi?
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)
Grazie
Enzo
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
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.
Grazie,
se pur duplicando l’intero preventivo in ogni sua parte, è possibile gestire le revisioni con il web service?
Buona Domenica
Enzo
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.
Grazie
per la cortesia, la velocità e la chiarezza delle sue risposte
Saluti
Enzo
Buona sera,
cerco un aiuto perché non riesco a creare un json per fare una select con il group by.
Grazie
Non è possibile utilizzare il “group by” via web service: occorre ottenere i dati dettagliati e poi elaborarli esternamente.
Grazie
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
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).
Grazie
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
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
}
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
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
}
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
Ok, tutto chiaro, logico ed ovviamente funzionante !!
grazie infinite
Enzo
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
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.
Si nessun problema… ero andato nel pallone io!! Semplicemente il client si connetteva ad un’azienda diversa da quella in cui avevo fatto l’importazione dei record…
Grazie
Enzo
Buona sera
ho la necessità di utilizzare il webservice per fare una select che restituisca le righe di EB_RigheOrdiniClienti che hanno QtaEvasa < Quantita, riferite ad un determinato cliente possibilmente passando il codice del cliente ma nonostante i miei tentativi non sono riuscito a impostare il json. E' possibile farlo? Se si per cortesia mi può fare un esempio?
Grazie
Enzo Callegari
Se ho capito bene la richiesta, dovrebbe essere simile a questa query:
{ “jsonrpc”: “2.0”, “id” :1,
“method”: “select_data”,
“params”: [“283f6abad826572a9f964cf362242dde”,
“EB_RigheOrdiniClienti”, [“EB_RigheOrdiniClienti.ref_OrdineCliente.NumeroInterno”, “EB_RigheOrdiniClienti.NumeroRiga”, “EB_RigheOrdiniClienti.DescArticolo”],
“EB_RigheOrdiniClienti.QtaEvasa < EB_RigheOrdiniClienti.Quantita AND EB_RigheOrdiniClienti.ref_OrdineCliente.ref_Cliente.Codice = 'C00101'"
]
}
Buona sera sig. Toso,
si ha capito bene vorrei fare proprio in questo modo, ed è quello che ho provato a fare anch’io.
Il problema è che il risultato che ottengo è:
{“jsonrpc”:”2.0″,”id”:null,”error”:{“code”:-32700,”message”:”parse error: invalid object key (must be a string)\n \”jsonrpc\”:\t\”2.0\”, \t\”id\”:\t1, \t:\tfalse }\n (right here) ——^\n”}}
( questo risultato è ottenuto sostituendo il sid ed il codice cliente al suo esempio.)
A lei con il suo esempio ritorna un result valido?
Grazie Enzo
Sì, la query è corretta e ritorna un risultato valido. Forse la richiesta è malformata o vi sono dei caratteri invisibili causati forse da un copia/incolla… L’errore in esame viene ritornato da quale ambiente? Un client REST o da FileMaker?
Posso consigliare di verificare quale parte della richiesta genera errore, magari partendo da una richiesta più semplice che ritorni dei dati corretti e poi aggiungendo un “pezzo” alla volta per poter identificare la causa del problema
L’ambiente è Mac, mentre le richieste al ws vengono eseguite da un eseguibile sviluppato da me con Xojo.
Ho provato ad implementare il suo esempio senza passare per il copia incolla ed ora il risultato che ottengo è questo :
{
“result”: [[“EB_RigheOrdiniClienti.ref_OrdineCliente.NumeroInterno”, “EB_RigheOrdiniClienti.NumeroRiga”, “EB_RigheOrdiniClienti.DescArticolo”]],
“jsonrpc”: “2.0”,
“error”: null,
“id”: 0
}
Ho provato a dividere la where e il result ora è un risultato valido sia per:
EB_RigheOrdiniClienti.QtaEvasa < EB_RigheOrdiniClienti.Quantita
che per
EB_RigheOrdiniClienti.ref_OrdineCliente.ref_Cliente.Codice = 'C01050'
ma legate insieme con "and" il result è quello indicato sopra
Il risultato è vuoto, quindi significa che non ci sono righe che soddisfano la select, ma la chiamata è andata a buon fine, infatti “result” contiene la prima riga con la lista dei nomi dei campi e null’altro. Probabilmente i due insiemi che compongono i risultati ottenuti separatamente sono disgiunti.
Buon giorno sig. Toso,
tutto ok.
Il problema non era la select, ma le righe degli ordini.
Mi spiego meglio, sono ordini che ho importato da un altro software e purtroppo ci sono stati problemi con l’importazione.
Grazie per disponibilità e professionalità
Enzo
Callegari
Buon giorno sig. Toso,
i suffissi di preventivi, ordini e doc fiscali possono essere abbinati in modo automatico agli utenti?
Es. Utente Mario suffisso MA, Paolo PA
Grazie
Enzo Callegari
No, i suffissi sono abbinati alla tipologia dei documenti.
Ok
Grazie
Enzo
Callegari
Buon giorno sig. Toso,
le istanze del webservice (il sid ) hanno una forma di timeout?
Mi succede che se l’istanza rimane inattiva per diversi minuti
devo richiedere un nuovo sid.
Come posso intervenire perchè questo non avvenga?
Grazie
Enzo Callegari
Sì, esiste un parametro di timeout delle sessioni web, è presente nella configurazione del server, sezione “Servizio web”. Usualmente è impostato a 15 minuti e viene rinnovato ogni volta che si effettua una richiesta, quindi la sessione scade “timeout minuti” dopo l’ultima richiesta. Quindi si può tenere “viva” la sessione eseguendo una richiesta periodica, oppure aumentare il timeout nella configurazione, oppure – ancora meglio – gestire l’errore che torna una sessione scaduta richiedendo, in tal caso, una nuova sessione.
Grazie
Enzo Callegrari
Buon sera sig. Toso,
ho difficoltà a fare le select con l’ordinamento desc.
Quì sotto un esempio semplificato di una select che non mi funziona.
Per cortesia può aiutarmi a capire cosa stò sbagliando?
Grazie
Enzo Callegari
{
“jsonrpc”: “2.0”,
“id”: “0”,
“method”: “select_data”,
“params”: [“37e5fee4494d5a4bbc965bc369b20920”, “EB_DocumentiFiscali”, [“EB_DocumentiFiscali.id”, “EB_DocumentiFiscali.NumeroProgressivo”, “EB_DocumentiFiscali.RagioneSociale”], “EB_DocumentiFiscali.ref_Tipologia.Codice = ’01’ and EB_DocumentiFiscali.DataDocumento >= ‘2016-05-10’ and EB_DocumentiFiscali.DataDocumento <= '2016-05-15'", "", "EB_DocumentiFiscali.RagioneSociale"]
}
Spero di interpretare bene la richiesta, perché immagino che il valore “EB_DocumentiFiscali.RagioneSociale” sia relativo al parametro “order_by”, di conseguenza non capisco il valore “” che lo precede. Il parametro “order_desc” è quello successivo a “order_by” e deve avere un valore true (ordinamento decrescente) o false (ordinamento crescente, che è il default). Quindi:
{
"jsonrpc": "2.0",
"id": 1,
"method": "select_data",
"params": ["37e5fee4494d5a4bbc965bc369b20920", "EB_DocumentiFiscali", ["EB_DocumentiFiscali.id", "EB_DocumentiFiscali.NumeroProgressivo", "EB_DocumentiFiscali.RagioneSociale"], "EB_DocumentiFiscali.ref_Tipologia.Codice = '01' and EB_DocumentiFiscali.DataDocumento >= '2016-05-10' and EB_DocumentiFiscali.DataDocumento <= '2016-05-15'", "EB_DocumentiFiscali.RagioneSociale", true]
}
Buon giorno e Buon Anno
ho interpretato male l’esempio, ora come suggerito da lei funziona.
grazie per la risposta.
Enzo Callegari
Buon giorno sig. Toso,
come sono legati il gruppo del cliente e la categoria degli articoli?
es:
i clienti del gruppo 1 hanno uno sconto di 10 sui prodotti della categoria a e 15 sugli articoli della categoria b.
i clienti del gruppo 2 hanno uno sconto di 20 sui prodotti della categoria a e 25 sugli articoli della categoria b.
Grazie
Enzo Callegari
Salve, credo che per rispondere correttamente alla domanda manchi un contesto di partenza: mi pare di intuire che stiamo parlando dell’archivio Classi di Sconto, ma non posso esserne certo. In tal caso, esistono le tabelle EB_ClassiSconto e EB_RigheClassiSconto che possono essere collegate ad un solo cliente (EB_ClassiSconto.ref_ClienteFornitore) o ad un gruppo (EB_ClassiSconto.ref_GruppoClienteFornitore), all’interno di ogni riga poi sono descritte le regole per l’applicazione degli sconti: per singolo articolo (EB_RigheClassiSconto.ref_Articolo) o per categoria (EB_RigheClassiSconto.ref_CategoriaMerceologica) o per produttore (EB_RigheClassiSconto.ref_Produttore). Inoltre ogni riga può indicare se si tratta di uno sconto (EB_RigheClassiSconto.Sconto) o, nel caso del singolo articolo, di un prezzo netto (EB_RigheClassiSconto.PrezzoNetto) da utilizzare al posto del prezzo di vendita standard.
Buona sera sig. Toso,
tutto ok con le classi di sconto grazie. Con le feste una fetta di panettone ci nascondeva la voce nella barra laterale.
A proposito della barra laterale è possibile creare un tag/label con dei preferiti ? Con il nuovo anno il cliente per cui ho sviluppato l’interfaccia personalizzata è passato definitivamente da Tibet a Konga e stando a fianco dei suoi operatori, mi sono reso conto che personalizzare quella barra, sarebbe un bel modo per personalizzare i menu di accesso alle funzioni, in base al tipo di lavoro che svolge l’operatore di ogni singolo client.
Saluti
Enzo Callegari
In realtà esiste già una gestione dei preferiti per la barra laterale di navigazione: cliccando il simbolo del segnalibro che si trova accanto ad ogni comando si indica se quel comando è un comando “preferito”, quindi si può utilizzare l’apposito pulsante in alto a destra, accanto al box di ricerca, per abilitare la vista dei soli preferiti o di tutti i comandi.
Ottimo !!
Così si lavora molto meglio!!
Grazie
Enzo Callegari
Buona sera sig. Toso,
come posso fare per sapere se un record è
stato bloccato da un JSON “lock_resource” ?
Vorrei sapere se il record è bloccato prima di caricarlo in un Form.
Grazie
Enzo Callegari
Chiamando lock_resource(): se è già stato impegnato da una lock_resource da un’altra sessione, la seconda lock_resource tornerà un errore.
Grazie per la risposta,
ho provato in vari modi ma non riesco ad impostare un JSON che mi dia la risposta.
Per cortesia potrebbe farmi un esempio.
Grazie
Enzo
Callegari
Per essere più chiaro le allego la chiamata che invio e la risposta che ottengo:
{“jsonrpc”:”2.0″,”id”:”0″,”method”:”lock_resource”,”params”:[“04a7d0c1e3c55f6cb67c142aa341a911″,”EB_OrdiniClienti”,”21093″]}
{
“result”: {
“answer”: 0,
“owner_data”: {
}
},
“jsonrpc”: “2.0”,
“error”: null,
“id”: 0
}
Inoltre non sono riuscito a capire se lock_resource e unlock_resource “interessano/influiscono” anche l’applicazione Konga e i suoi client o se invece “interessano/influiscono” solamente i client che si connettono via web service ( quelli personalizzati ).
La verifica del funzionamento della lock_resource non si può fare dalla stessa sessione/client: se una risorsa viene “bloccata” da una sessione webservice e poi la stessa sessione webservice richiede il blocco della stessa risorsa, Konga server riconosce che si tratta della stessa sessione/client e mantiene valido il “lock” precedente. Per ottenere un errore in seguito ad una chiamata lock_resource occorre per esempio iniziare a modificare una scheda cliente via Konga (senza poi premere registra) e contestualmente eseguire la lock_resource di EB_ClientiFornitori specificando l’ID della scheda che in quel momento è in modifica, in quel caso la lock_resource dovrebbe tornare un errore. Quindi credo di avere risposto anche alla domanda relativa al contesto in cui opera la lock_resource: vale per tutti i client e tutte le sessioni webservice.
Grazie mille,
ora è più chiaro, ma non ancora al 100% !
Se apro in modifica un record da Konga e poi dal mio client con la chiamata lock_resource il JSON effettivamente mi ritorna le info su chi ha bloccato il record.
Se però faccio la chiamata lock_resource con le medesime modalità prima dal mio client e poi provo a modificare il record da Konga, il record su Konga viene modificato e salvato senza nessun avviso di blocco.
Cosa stò sbagliando?
Grazie
Eno Callegari
Non sta sbagliando nulla: ha scoperto un errore di Konga server nella gestione della “lock_resource” quando eseguita dal web service. È stato aperto un ticket e appena la correzione sarà presente nella versione “stable” la informerò rispondendo a questo commento del blog. Grazie per la segnalazione.
Complimenti per la professionalità con cui porta avanti questo blog.
Le vorrei sottoporle un aspetto che mi ha fatto riflettere testando questa funzione. Se ho capito bene, per sapere se un record è bloccato devo provare a bloccarlo in modo che la risposta mi dica se è già stato bloccato da altri. Se la richiesta era solo a fini informativi nel caso il record non fosse stato bloccato da altre sessione, ora lo sarebbe dalla sessione che ha richiesto l’informazione, a questo punto è necessario ogni volta sbloccare il record.
Poter ottenere l’informazione senza bloccare il record credo sarebbe più logico, ad esempio con una chiamata dedicata alla sola info, oppure aggiungendo l’informazione alla risposta della chiamata “get_record”
Saluti
Enzo Callegari
Grazie per i complimenti, sono sempre benvenuti. Per quanto riguarda il suo suggerimento, può essere sicuramente una funzionalità utile ma attualmente non abbiamo ricevuto molte richieste in tal senso, per adesso chi utilizza il web service dovrà “accontentarsi” di utilizzare la lock_resource avendo cura di rilasciare la risorsa appena essa non è più utilizzata.
Ho fatto altre verifiche, anche il client che si connette con il ws può fare un Update di un record bloccato da Konga senza dare errore, anche se la chiamata lock_resource restituisce un risultato che dice che è bloccato dalla postazione di Konga.
Saluti
Enzo
Attualmente questo è il funzionamento normale del server: è onere del programma esterno verificare se le risorse sono state “bloccate” da altri client, il server funziona quasi come un database, bloccando effettivamente le risorse solo per il brevissimo periodo di tempo necessario all’aggiornamento. Non è escluso che in futuro questo modo di gestire le risorse possa cambiare nella direzione da lei ipotizzata, ma per adesso questo modo di funzionare è corretto.
Buonasera,
con il programmatore Enzo Callegari siamo arrivati ad un buon punto con l’interfaccia personalizzata.
Mi piace veramente la gestione di Konga dei preventivi con le revisioni.
Mi piacerebbe gestire le revisioni anche degli ordini. Come possiamo fare?
Grazie
Andrea Torresan
Bene, ci fa piacere che la nuova gestione dei preventivi riscuota “successo”. Attualmente il concetto di revisione dell’ordine non esiste, probabilmente sarebbe necessario introdurre dei nuovi stati oltre a: Inserito, Confermato, Evaso Parzialmente e Evaso Totalmente. Prendiamo buona nota della richiesta e la valuteremo per le prossime versioni del programma. Grazie per il suggerimento.
Buon giorno Sig. Toso,
ho notato che nell’inserimento di un DocumentoFiscale o di un OrdineCliente il campo NumeroRiga viene salvato con l’incremento corretto anche se lasciato vuoto. Invece per l’inserimento dei Preventivi con le stesse modalità la numerazione delle righe non avviene in modo corretto. In particolare si verificano doppioni di numeri per i valori 3 e 5, es: 1,2,3,3,4,5,5,6,7,8,9,10,11,12,13,14 etc etc…
Saluti
Enzo Callegari
Salve, abbiamo eseguito qualche verifica e non riusciamo a ripetere la sua segnalazione. Eseguendo una richiesta di inserimento di un preventivo con 10 righe – come qui sotto – le righe vengono correttamente numerate da 1 a 10.
{"jsonrpc":"2.0",
"method":"insert_record",
"params":["8576951f43bf564aa9e953c7ddc417be",
"EB_Preventivi","00000001","00000001", {
"EB_Preventivi.Indirizzo_Corr": "V.LE DELLE INDUSTRIE, 10/12",
"EB_Preventivi.RagioneSociale": "RAMBLA BELTING SPA",
"EB_Preventivi.ref_Azienda": 1,
"EB_Preventivi.val_ModalitaRicezione": 0,
"EB_Preventivi.val_ModalitaInvio": 0,
"EB_Preventivi.Email": "info@rambla.it",
"EB_Preventivi.TitoloCliente": "",
"EB_Preventivi.val_Nazione": 107,
"EB_Preventivi.ref_Indirizzo": 1,
"EB_Preventivi.ref_Vettore1": 9,
"EB_Preventivi.TSCreazione": "2017-01-24 11:19:20",
"EB_Preventivi.Indirizzo": "V.LE DELLE INDUSTRIE, 10/12",
"EB_Preventivi.ref_Tipologia": 8,
"EB_Preventivi.val_ModalitaTrasporto": 0,
"EB_Preventivi.Localita": "CERNUSCO S/N",
"EB_Preventivi.TotaleImponibile": 2067.93,
"EB_Preventivi.ScontoGlobale": "",
"EB_Preventivi.ref_Tipologia.Codice": "08",
"EB_Preventivi.CodiceFiscale": "",
"EB_Preventivi.val_NazioneCorr": 107,
"EB_Preventivi.CAP": "20063",
"EB_Preventivi.ref_Valuta": 1,
"EB_Preventivi.flags": 0,
"EB_Preventivi.ref_Agente": 1,
"EB_Preventivi.SpeseBolli": 0,
"EB_Preventivi.SpeseImballo": 0,
"EB_Preventivi.ImportoRitenuta": 0,
"EB_Preventivi.DataPrevConsegna": "0000-00-00",
"EB_Preventivi.TerminiConsegna": "",
"EB_Preventivi.DataRicezioneRichiesta": "2017-01-24",
"EB_Preventivi.NumeroInterno": 1,
"EB_Preventivi.CodiceCliente": "C00100",
"EB_Preventivi.EBMagic": 7642489019773251000,
"EB_Preventivi.CodISO": "IT",
"EB_Preventivi.ref_UtenteCreazione": 1,
"EB_Preventivi.DataRiesameISO2": "0000-00-00",
"EB_Preventivi.NettoAPagare": 2481.52,
"EB_Preventivi.GiorniValidita": 0,
"EB_Preventivi.Provincia": "MI",
"EB_Preventivi.DataCambio": "2017-01-24",
"EB_Preventivi.NumeroProgressivo": 1,
"EB_Preventivi.Provincia_Dest": "MI",
"EB_Preventivi.NumeroRevisione": 1,
"EB_Preventivi.Localita_Dest": "CERNUSCO S/N",
"EB_Preventivi.SpeseVarie": 0,
"EB_Preventivi.ref_BancaAzienda": 1,
"EB_Preventivi.val_NazioneDest": 107,
"EB_Preventivi.DataPreventivo": "2017-01-24",
"EB_Preventivi.CorteseAttenzione": "",
"EB_Preventivi.SpeseIncasso": 0,
"EB_Preventivi.RevisioneMadre": 0,
"EB_Preventivi.ref_Tipologia.val_TipoDocumento": 7,
"EB_Preventivi.TotaleIVA": 413.59,
"EB_Preventivi.ref_Tipologia.Suffisso": "",
"EB_Preventivi.ref_CondizioneConsegna": 1,
"EB_Preventivi.RagSoc_Corr": "RAMBLA BELTING SPA",
"EB_Preventivi.PartitaIVA": "08302040152",
"EB_Preventivi.val_AddSpese": 1,
"EB_Preventivi.ref_Tipologia.tra_Descrizione": "Preventivo",
"EB_Preventivi.TotaleDocumento": 2481.52,
"EB_Preventivi.SpeseTrasporto": 2.1,
"EB_Preventivi.val_Stato": 0,
"EB_Preventivi.ref_CondizionePagamento": 75,
"EB_Preventivi.Provincia_Corr": "MI",
"EB_Preventivi.ref_Cliente": 1,
"EB_Preventivi.Indirizzo_Dest": "V.LE DELLE INDUSTRIE, 10/12",
"EB_Preventivi.DataRichiesta": "2017-01-24",
"EB_Preventivi.Oggetto": "",
"EB_Preventivi.CondizioneAggiuntiva": "",
"EB_Preventivi.Suffisso": "",
"EB_Preventivi.CoefficienteCambio": 1,
"EB_Preventivi.RagSoc_Dest": "RAMBLA BELTING SPA",
"EB_Preventivi.CAP_Dest": "20063",
"EB_Preventivi.val_EsitoRiesame2": 0,
"EB_Preventivi.RifAggiuntivo1": "",
"EB_Preventivi.val_AddettoTrasporto": 0,
"EB_Preventivi.RifAggiuntivo2": "",
"EB_Preventivi.ref_UtenteModifica": 1,
"EB_Preventivi.RiferimentoRichiedente": "",
"EB_Preventivi.Localita_Corr": "CERNUSCO S/N",
"@rows": [
{
"EB_RighePreventivi.ref_Articolo": 1, "EB_RighePreventivi.Quantita": 1
},
{
"EB_RighePreventivi.ref_Articolo": 1, "EB_RighePreventivi.Quantita": 1
},
{
"EB_RighePreventivi.ref_Articolo": 1, "EB_RighePreventivi.Quantita": 1
},
{
"EB_RighePreventivi.ref_Articolo": 1, "EB_RighePreventivi.Quantita": 1
},
{
"EB_RighePreventivi.ref_Articolo": 1, "EB_RighePreventivi.Quantita": 1
},
{
"EB_RighePreventivi.ref_Articolo": 1, "EB_RighePreventivi.Quantita": 1
},
{
"EB_RighePreventivi.ref_Articolo": 1, "EB_RighePreventivi.Quantita": 1
},
{
"EB_RighePreventivi.ref_Articolo": 1, "EB_RighePreventivi.Quantita": 1
},
{
"EB_RighePreventivi.ref_Articolo": 1, "EB_RighePreventivi.Quantita": 1
},
{
"EB_RighePreventivi.ref_Articolo": 1, "EB_RighePreventivi.Quantita": 1
}
]
}],
"id":1
}
Buon giorno Sig. Toso
grazie per l’interessamento.
In effetti il problema si verifica random, prima il cliente mi ha segnalato altre incongruenze così le ho fatto inviare il db.
Saluti
Enzo Callegari
Buon giorno Sig. Toso,
ho analizzato il db del cliente ed ho riscontrato che come segnalava il cliente ci sono state diverse imprecisione nella numerazioni righe. Solo per le righe con un NumeroRiga di superiore a 15000 sono riuscito a trovare una spiegazione che dipendeva da un utilizzo non cerreto dello strumento. Mentre per i doppioni non sono riuscito a dare una spiegazione. In ogni caso ora ho implementato la numerazione forzata è dai test sembra non sbagliare più. Ho inoltre implementato il salvataggio su file di tutti i json che inseriscono o che modificano un documento così da avere più informazioni in caso di altri errori.
Per le esigenze del Cliente le righe dei documenti non possono essere inserite solo con il ref_articolo come dal suo esempio.
Non so se questo può essere una possibile causa delle imprecisioni.
Le allego un esempio di quello che viene inviato al ws:
{
“jsonrpc”: “2.0”,
“id”: “0”,
“method”: “insert_record”,
“params”: [“a11e4c2e3ddd5f7eb11618b533a1c9d0”, “EB_Preventivi”, “00000001”, “00000002”, {
“EB_Preventivi.code_Azienda”: “00000001”,
“EB_Preventivi.code_Tipologia”: “08”,
“EB_Preventivi.code_TipologiaOC”: “09”,
“EB_Preventivi.code_Valuta”: “EUR”,
“EB_Preventivi.NumeroProgressivo”: “2847”,
“EB_Preventivi.code_Cliente”: “C01050”,
“EB_Preventivi.CodiceCliente”: “C01050”,
“EB_Preventivi.RagioneSociale”: “FIL SERRAMENTI SRL”,
“EB_Preventivi.Indirizzo”: “VIA ZECCHINA, 21”,
“EB_Preventivi.Localita”: “QUINTO DI TREVISO”,
“EB_Preventivi.CAP”: “31055”,
“EB_Preventivi.Provincia”: “TV”,
“EB_Preventivi.PartitaIVA”: “00239940265”,
“EB_Preventivi.Oggetto”: “”,
“EB_Preventivi.DataPreventivo”: “2017-01-25”,
“EB_Preventivi.code_CondizionePagamento”: “RB69”,
“EB_Preventivi.val_Stato”: “1”,
“EB_Preventivi.NumeroRevisione”: “1”,
“EB_Preventivi.DataPrevConsegna”: “0000-00-00”,
“EB_Preventivi.ref_BancaAzienda”: “2”,
“EB_Preventivi.Note”: “”,
“EB_Preventivi.TotaleImponibile”: “”,
” “: “”,
“@rows”: [{
“EB_RighePreventivi.code_Articolo”: “FS QUAR TOND 012”,
“EB_RighePreventivi.NumeroRiga”: “1”,
“EB_RighePreventivi.CodArticolo”: “FS QUAR TOND 012”,
“EB_RighePreventivi.DescArticolo”: “FRESE 1/4 DI TONDO D=120 R=5 SP=12 Z=3”,
“EB_RighePreventivi.code_RigheUnitaMisura”: “PZ”,
“EB_RighePreventivi.ValoreUnitario”: “165.57”,
“EB_RighePreventivi.Sconto”: “20+10”,
“EB_RighePreventivi.ValoreUnitarioNetto”: “119.21”,
“EB_RighePreventivi.Quantita”: “1”,
“EB_RighePreventivi.PrezzoAcquisto”: “76.164500”,
“EB_RighePreventivi.PrezzoVendita”: “165.575000”,
“EB_RighePreventivi.ref_AliquotaIVA”: “15”
}, {
“EB_RighePreventivi.code_Articolo”: “BRI.101.001”,
“EB_RighePreventivi.NumeroRiga”: “2”,
“EB_RighePreventivi.CodArticolo”: “BRI.101.001”,
“EB_RighePreventivi.DescArticolo”: “PUNTA PER PANTOGRAFO HM D=8 T=25 L=55 S=9,5×25 Z=2”,
“EB_RighePreventivi.code_RigheUnitaMisura”: “PZ”,
“EB_RighePreventivi.ValoreUnitario”: “27.9”,
“EB_RighePreventivi.Sconto”: “20+10”,
“EB_RighePreventivi.ValoreUnitarioNetto”: “20.09”,
“EB_RighePreventivi.Quantita”: “1”,
“EB_RighePreventivi.PrezzoAcquisto”: “11.160000”,
“EB_RighePreventivi.PrezzoVendita”: “27.900000”,
“EB_RighePreventivi.ref_AliquotaIVA”: “15”
}, {
“EB_RighePreventivi.code_Articolo”: “G 301”,
“EB_RighePreventivi.NumeroRiga”: “3”,
“EB_RighePreventivi.CodArticolo”: “G 301”,
“EB_RighePreventivi.DescArticolo”: “GUARNIZIONE BRONZO ral 8019”,
“EB_RighePreventivi.code_RigheUnitaMisura”: “MT”,
“EB_RighePreventivi.ValoreUnitario”: “0.5”,
“EB_RighePreventivi.Sconto”: “20+10”,
“EB_RighePreventivi.ValoreUnitarioNetto”: “0.36”,
“EB_RighePreventivi.Quantita”: “700”,
“EB_RighePreventivi.PrezzoAcquisto”: “0.228000”,
“EB_RighePreventivi.PrezzoVendita”: “0.500000”,
“EB_RighePreventivi.ref_AliquotaIVA”: “15”
}]
}]
}
Grazie
Enzo Callegari
L’esempio dove veniva utilizzato il campo “ref_Articolo” non è vincolante: è solo casuale, l’inserimento di codice e descrizione è altrettanto valido. Per quanto riguarda il numero di riga, in attesa di maggiori informazioni sulla reale causa del suo problema, la soluzione di indicare sempre il numero di riga al momento dell’inserimento mi pare adeguata. Grazie per l’aggiornamento.
Buona sera Sig. Toso,
sto testando i tag per la classificazione degli articoli e la trovo molto valida per molti aspetti. In questo momento la vorrei utilizzare per organizzare gli articoli con la logica del catalogo del cliente.
Vorrei inserire una colonna con i tag nella lista degli Articoli ma non ho trovato un modo per farlo…..
Esiste?
Saluti
Enzo Callegari
Buona sera Sig. Toso,
sto cercando di creare un json per modificare un ordine della tabella EB_OrdiniFornitori ma mi ritorna sempre un errore.
invio questo:
{
“jsonrpc”: “2.0”,
“id”: “0”,
“method”: “update_record”,
“params”: [“2cbbfac1666656a8ae02710f430360ac”, “EB_OrdiniFornitori”, “629”, “Null”, “00000001”, “00000002”, {
“EB_OrdiniFornitori.code_Tipologia”: “10”,
“EB_OrdiniFornitori.code_Valuta”: “EUR”,
“EB_OrdiniFornitori.code_Azienda”: “00000001”,
“EB_OrdiniFornitori.code_Fornitore”: “F0330”,
“EB_OrdiniFornitori.DenominazioneFornitore”: “SCHLEGEL SRL”,
“EB_OrdiniFornitori.IndirizzoFornitore”: “VIA MIGLIOLI, 9”,
“EB_OrdiniFornitori.LocalitaFornitore”: “SEGRATE”,
“EB_OrdiniFornitori.CAPFornitore”: “20090”,
“EB_OrdiniFornitori.ProvinciaFornitore”: “MI”,
“EB_OrdiniFornitori.PartitaIVAFornitore”: “04164690150”,
“EB_OrdiniFornitori.val_AddSpese”: “1”,
“EB_OrdiniFornitori.DenominazioneFatt”: “Torresan Srl”,
“EB_OrdiniFornitori.IndirizzoFatt”: “Via G. Pastore, 28”,
“EB_OrdiniFornitori.LocalitaFatt”: “Montebelluna”,
“EB_OrdiniFornitori.CapFatt”: “31044”,
“EB_OrdiniFornitori.ProvinciaFatt”: “TV”,
“EB_OrdiniFornitori.DenominazioneDestinazione”: “Torresan Srl”,
“EB_OrdiniFornitori.IndirizzoDest”: “Via G.Pastore, 28”,
“EB_OrdiniFornitori.LocalitaDest”: “Montebelluna”,
“EB_OrdiniFornitori.CapDest”: “31044”,
“EB_OrdiniFornitori.ProvinciaDest”: “TV”,
“EB_OrdiniFornitori.code_CondizionePagamento”: “RB6P”,
“EB_OrdiniFornitori.code_CondizioneConsegna”: “02”,
“EB_OrdiniFornitori.code_Banca”: “”,
“EB_OrdiniFornitori.DataOrdine”: “2016-12-22”,
“EB_OrdiniFornitori.code_CausaleMagazzino”: “CAFO”,
“EB_OrdiniFornitori.code_TitDepEntrata”: “0101”,
“EB_OrdiniFornitori.Note”: “Rif. OR. 4D ANF0330-051\n”,
“EB_OrdiniFornitori.TotaleImponibile”: “198.4”,
“@rows”: [{
“EB_RigheOrdiniFornitori.ref_Articolo”: “34819”,
“EB_RigheOrdiniFornitori.NumeroRiga”: “1”,
“EB_RigheOrdiniFornitori.DescArticolo”: “GUARNIZIONE GRIGIA ral 7035”,
“EB_RigheOrdiniFornitori.code_RigheUnitaMisura”: “MT”,
“EB_RigheOrdiniFornitori.ValoreUnitario”: “0.248000”,
“EB_RigheOrdiniFornitori.Sconto”: “0”,
“EB_RigheOrdiniFornitori.ValoreUnitarioNetto”: “0.248000”,
“EB_RigheOrdiniFornitori.Quantita”: “800”,
“EB_RigheOrdiniFornitori.QtaEvasa”: “0”,
“EB_RigheOrdiniFornitori.ref_AliquotaIVA”: “15”
}]
}]
}
L’errore che ritorna è:
{“jsonrpc”:”2.0″,”id”:null,”error”:{“code”:5121,”message”:”Non è possibile modificare il Numero Progressivo di un ordine confermato o evaso!”}}
la cosa che non capisco è che non viene passato il campo NumeroProgressivo….
Per cortesia può aiutarmi a capire cosa sto sbagliando?
Grazie
Enzo Callegari
Vi sono alcuni campi che è obbligatorio passare ai fini dei controlli che esegue Konga Server: ref_Tipologia (o code_Tipologia), NumeroProgressivo e Suffisso; la cosa migliore sarebbe quella di leggere l’ordine con una “get_record”, modificare i dati ed eseguire l’aggiornamento con una chiamata “update_record”, in tal modo si è sicuri che tutti i dati letti con la get_record saranno poi passati alla update_record, anche quelli che non interessa modificare.
Ok
risolto
Grazie
Enzo Callegari
Grazie,
faccio qualche prova
Buon giorno sig. Toso,
sto tentando di impostare un json per la generazione di un documento nella tabella EB_CaricoScarico ma non riesco a capire l’errore che mi ritorna….
per cortesia può aiutarmi a capire cosa sto sbagliando?
questo è quello che invio:
{
“jsonrpc”: “2.0”,
“id”: “0”,
“method”: “insert_record”,
“params”: [“8acb5061e37358fab4bbc220f5bc9f07”, “EB_CaricoScarico”, “00000001”, “00000002”, {
“EB_CaricoScarico.code_Azienda”: “00000001”,
“EB_CaricoScarico.code_Esercizio”: “00000002”,
“EB_CaricoScarico.code_Valuta”: “EUR”,
“EB_CaricoScarico.DataRegistrazione”: “2017-02-10”,
“EB_CaricoScarico.ref_CausaleMagazzino”: “1”,
“EB_CaricoScarico.code_ClienteFornitore”: “F0330”,
“EB_CaricoScarico.ref_CondizioneConsegna”: “2”,
“EB_CaricoScarico.ref_TitDepEntrata”: “3”,
“@rows”: [{
“EB_RigheCaricoScarico.NumeroRiga”: “1”,
“EB_RigheCaricoScarico.ref_RigaOrdineFornitore”: “2237”,
“EB_RigheCaricoScarico.NumeroRigaProvenienza”: “1”,
“EB_RigheCaricoScarico.Quantita”: “1000”,
“EB_RigheCaricoScarico.ValoreUnitario”: “0.26”,
“EB_RigheCaricoScarico.Sconto”: “0”,
“EB_RigheCaricoScarico.ValoreUnitarioNetto”: “0.26”,
“EB_RigheCaricoScarico.ref_Articolo”: “32191”,
“EB_RigheCaricoScarico.code_RigaUnitaMisura”: “MT”
}]
}]
}
la risposta è:
{“jsonrpc”:”2.0″,”id”:null,”error”:{“code”:5013,”message”:”Non è stato specificato il codice articolo per la riga 1!”}}
nella documentazione però non trovo un campo con questo nome….
In questo caso il codice articolo viene identificato da “ref_Articolo”, è probabile che nell’azienda di destinazione non esista un articolo con id = 32191. Inoltre – ma non riguarda la causa dell’errore – ho notato che viene valorizzato il campo “NumeroRigaProvenienza”, ma esso è relativo ai movimenti di carico-scarico automatici (generati da altri mov. di carico-scarico) e credo che in questo caso dovrebbe essere omesso, in modo che venga valorizzato con il valore di default
Grazie per la velocità della risposta.
Ho controllato, l’articolo con id “32191” esiste ed il suo campo ref_Azienda è null. Inoltre come da lei suggerito ho eliminato la riga del campo NumeroRigaProvenienza ma l’errore non cambia….
Saluti
Enzo Callegari
Facendo una prova con il database con i dati di esempio non siamo riusciti a ripetere l’errore che ci ha comunicato, ma abbiamo invece notato che il campo che nel suo esempio è stato riportato come “EB_RigheCaricoScarico.code_RigaUnitaMisura” dovrebbe in realtà essere “EB_RigheCaricoScarico.code_RigheUnitaMisura”, corretto il nome del campo, la richiesta è andata a buon fine. Questa la richiesta che abbiamo usato con l’azienda di esempio:
{"jsonrpc": "2.0",
"id": "0",
"method": "insert_record",
"params": ["c8687f4f5a845a51b4b37daadab280e0", "EB_CaricoScarico", "00000001", "00000001", {
"EB_CaricoScarico.code_Azienda": "00000001",
"EB_CaricoScarico.code_Esercizio": "00000001",
"EB_CaricoScarico.code_Valuta": "EUR",
"EB_CaricoScarico.DataRegistrazione": "2000-02-10",
"EB_CaricoScarico.ref_CausaleMagazzino": "1",
"EB_CaricoScarico.code_ClienteFornitore": "F00114",
"EB_CaricoScarico.ref_CondizioneConsegna": "2",
"EB_CaricoScarico.ref_TitDepEntrata": "1",
"@rows": [{
"EB_RigheCaricoScarico.NumeroRiga": "1",
"EB_RigheCaricoScarico.Quantita": "1000",
"EB_RigheCaricoScarico.ValoreUnitario": "0.26",
"EB_RigheCaricoScarico.Sconto": "0",
"EB_RigheCaricoScarico.ValoreUnitarioNetto": "0.26",
"EB_RigheCaricoScarico.ref_Articolo": "1",
"EB_RigheCaricoScarico.code_RigheUnitaMisura": "PZ"
}]
}]
}
Buon giorno,
confermo,
l’errore era dove mi ha segnalato lei.
Ora tutto funziona.
Grazie
Enzo Callegari
Buon giorno sig. Toso,
avrei bisogno di capire a quale campo del db dell’archivio clienti fa riferimento il popupmenu Affidabilita alla sessione Fido e Target.
Grazie
Enzo Callegari
Credo che il campo a cui si riferisce sia “val_TipoAffidabilita” di “EB_DatiCliForAzienda”
http://public.easybyte.it/docs/current/technical/datadict/eb_daticliforazienda.html#val-tipoaffidabilita
e questi sono i valori ammessi: http://public.easybyte.it/docs/current/technical/datadict/choice_tipiaffidabilita.html#choice-tipiaffidabilita
Buon giorno,
si cercavo proprio quello, ma lo cercavo nell’archivio ClientiFornitori….
Grazie
Enzo Callegari
Buon giorno,
i campi RifAggiuntivo1 e RifAggiuntivo2 nelle Tabelle EB_Preventivi e EB_OridiniClienti sono campi a descrizione libera che possono essere utilizzati per memorizzare informazioni extra relative al documento?
Grazie
Enzo Callegari
Sì, è corretto.
Grazie
Buon giorno Sig. Toso,
stiamo valutando le funzionalità dell’archivio Listini e a proposito avrei bisogno di sapere se è possibile abbinare un listino solo ad una specifica Tipologia Prodotti o in alternativa ad una Categoria Merceologia. Se non è possibile fare abbinamenti è eventualmente possibile abbinare il listino alla singola riga del documento ( preventivo, ordine, ddt…) e non a tutto il documento?
NB. tutti i documenti devo inserili e gestirli sempre con le chiamate al web service.
Grazie
Enzo Callegari
I prezzi di un listino vengono creati sempre per tutti gli articoli ed il listino abbinato ad un documento è uno solo e definito nell’intestazione del documento. È possibile utilizzare l’archivio delle classi di sconto per definire dei prezzi specifici per un cliente o un gruppo di clienti che poi possono variare in base al produttore, alla categorie o al singolo articolo di magazzino.
Molto chiaro.
Per quello che serve al cliente meglio continuare a gestire la cosa con le classi di sconto…
Grazie
Enzo
buon giorno, c’è qualcuno che ha creato un file con filemaker 16 che riesce a legger KONGA?
(intendo dire usando i web sevice)
Abbiamo diversi utenti di FileMaker che utilizzano i web service utilizzando l’estensione “BaseElements”, immagino che la stessa modalità possa essere utilizzata anche per la versione 16
Buona sera sig. Toso,
che dati contengono le tabelle EB_FTS_chunk e EB_FTS_queue?
Possono essere svuotate?
Grazie
Enzo Callegari
EB_FTS_chunk e EB_FTS_queue contengono i dati dell’indicizzazione per le ricerche “full-text”, se non si intende utilizzare le ricerche “full-text” si può eliminare il contenuto a patto che sia stata disabilitata l’indicizzazione di ricerca nelle preferenze del server, sezione “avanzate”. Per eliminare il contenuto delle tabelle in esame è possibile utilizzare il comando “Cancella l’indice di ricerca” dalla finestra del Konga Manager, quando il database è selezionato e quindi, successivamente, disabilitare l’indicizzazione di ricerca nelle preferenze del server. In alternativa è possibile disabilitare l’indicizzazione di ricerca e successivamente, operando direttamente sul database, eseguire una TRUNCATE delle tabelle.
Grazie,
lo avevo intuito ma preferivo avere una Vs conferma.
Enzo
Buon giorno Sig. Toso
analizzando una problematica mi sono accorto che ho passato al webservice json con informazioni non coerenti/corrette ma che comunque vanno a buon fine.
più precisamente
i campi che ho sbagliato a compilare sono :
EB_DocumentiFiscali.ref_Tipologia
EB_OrdiniClienti.ref_TipologiaDF
ho inserito gli id riferiti a record della tabella EB_TipologieDocumenti che sono corretti per la tipologia di documento ma che appartengono ad una azienda diversa da quella del documento.
il record con i EB_TipologieDocumenti.id = 21 ha come ref_Azienda = 2
il record con i EB_TipologieDocumenti.id = 11 ha come ref_Azienda = 3
entrambe le tipologie sono Documento di trasporto ma di aziende diverse
visto questo non potendo ricreare tutti i documenti ( in un db di test ) ho pensato di forzare i record ne db con:
/// ddt
Update EB_DocumentiFiscali SET EB_DocumentiFiscali.ref_Tipologia = 21 WHERE EB_DocumentiFiscali.ref_Tipologia = 11
/// ordini_clienti
Update EB_OrdiniClienti SET EB_OrdiniClienti.ref_TipologiaDF = 21 WHERE EB_OrdiniClienti.ref_TipologiaDF = 11
Dopo la variazione ad una prima analisi sembra risolta la problematica che mi ha fatto scovare questa imprecisione.
E’ corretto quello che ho fatto ?, sufficiente ?
Ci sono altre tabelle interessati da EB_TipologieDocumenti.id ?
grazie
Enzo Callegari
Faremo qualche verifica per capire come mai il Konga Server non ha risposto con un errore in questo caso. per quanto riguarda la domanda, se si fosse trattata di una situazione “in produzione” sarebbe stato meglio eliminare tutti i documenti e ricrearli, se si tratta di un ambiente di sviluppo la query di update credo che possa essere sufficiente.
In linea di massima forse sarebbe meglio passare il campo “code_”, invece del campo “ref_”, ad esempio “EB_DocumentiFiscali.code_Tipologia” (usando come valore il codice della tipologia documento), perché in questo modo il server esegue delle verifiche aggiuntive e questo problema non si sarebbe posto: attualmente passando il “ref_” l’onere del controllo è delegato all’applicazione esterna e il valore, se esistente nel DB, viene accettato senza eseguire i controlli aggiuntivi.
Buon giorno Sign. Toso,
grazie per la risposta.
per quanto riguarda l’invio dei futuri JSON seguirò le Vs indicazioni.
Per quanto riguarda invece la correzione degli errori vedo molto complicato ricreare tutti i documenti, sono diverse migliaia.
Preferirei correggere gli id con le query come specificato nel post ed eventualmente se necessita passarne altre.
Quali altre cose devo controllare se modifico gli id?
Che tipo di problematiche potrebbero sorgere ?
grazie
Enzo Callegari
In linea di massima non dovrebbe sorgere nessun problema, le schede modificate in questo modo riporteranno nelle informazioni la dicitura “modificato da terze parti”
Grazie
Credo che il problema nasca dal fatto che non viene passato il parametro “code_azienda”, probabilmente – ipotizzando un codice azienda = 00000001 – la richiesta dovrebbe essere simile a questa:
{
“jsonrpc”: “2.0”,
“id”: “1”,
“method”: “delete_record”,
“params”: [“5d3125e0e6255a27bb0b66750d050e9f”, “EB_OrdiniClienti”, “24411”, null, “00000001”]
}
Buon giorno Sig. Toso,
ho fatto le modifiche e sembra essere tutto ok per quanto riguarda Konga.
Ho invece qualche problema con la cancellazione degli ordini con il WS.
la stessa procedura che utilizzo per cancellate tutto ora mi da questo errore:
{
“jsonrpc”: “2.0”,
“error”: {
“code”: 1999,
“message”: “Get stato archivi cache query error 2201 (idAzienda = 0)”
},
“id”: null
}
questo è il json che ha creato l’ordine:
{
“jsonrpc”: “2.0”,
“id”: “0”,
“method”: “insert_record”,
“params”: [“5d3125e0e6255a27bb0b66750d050e9f”, “EB_OrdiniClienti”, “00000001”, “00000002”, {
“EB_OrdiniClienti.code_Azienda”: “00000001”,
“EB_OrdiniClienti.code_Tipologia”: “09”,
“EB_OrdiniClienti.code_Valuta”: “EUR”,
“EB_OrdiniClienti.NumeroProgressivo”: “24402”,
“EB_OrdiniClienti.code_Cliente”: “C01050”,
“EB_OrdiniClienti.CodiceCliente”: “C01050”,
“EB_OrdiniClienti.RagioneSociale”: “FIL SERRAMENTI SRL”,
“EB_OrdiniClienti.Indirizzo”: “VIA ZECCHINA, 21”,
“EB_OrdiniClienti.Localita”: “QUINTO DI TREVISO”,
“EB_OrdiniClienti.CAP”: “31055”,
“EB_OrdiniClienti.Provincia”: “TV”,
“EB_OrdiniClienti.PartitaIVA”: “00239940265”,
“EB_OrdiniClienti.code_CondizionePagamento”: “-RB6090”,
“EB_OrdiniClienti.code_CondizioneConsegna”: “02”,
“EB_OrdiniClienti.code_Banca”: “00180”,
“EB_OrdiniClienti.ref_BancaAzienda”: “2”,
“EB_OrdiniClienti.DataOrdine”: “2017-11-21”,
“EB_OrdiniClienti.code_CausaleMagazzino”: “SCCL”,
“EB_OrdiniClienti.code_TitDepUscita”: “0101”,
“EB_OrdiniClienti.val_Stato”: “1”,
“EB_OrdiniClienti.code_TipologiaDF”: “01”,
“EB_OrdiniClienti.NumPreventivo”: “”,
“EB_OrdiniClienti.Note”: “”,
“EB_OrdiniClienti.TotaleImponibile”: “”,
“EB_OrdiniClienti.val_Sospeso”: “0”,
“@rows”: [{
“EB_RigheOrdiniClienti.code_Articolo”: “FS QUAR TOND 012”,
“EB_RigheOrdiniClienti.NumeroRiga”: “1”,
“EB_RigheOrdiniClienti.DescArticolo”: “FRESE 1/4 DI TONDO D=120 R=5 SP=12 Z=3”,
“EB_RigheOrdiniClienti.code_RigheUnitaMisura”: “PZ”,
“EB_RigheOrdiniClienti.ValoreUnitario”: “165.57”,
“EB_RigheOrdiniClienti.Sconto”: “20+10”,
“EB_RigheOrdiniClienti.ValoreUnitarioNetto”: “119.21”,
“EB_RigheOrdiniClienti.Quantita”: “1”,
“EB_RigheOrdiniClienti.QtaEvasa”: “0”,
“EB_RigheOrdiniClienti.PrezzoAcquisto”: “76.164500”,
“EB_RigheOrdiniClienti.PrezzoVendita”: “165.575000”,
“EB_RigheOrdiniClienti.ref_AliquotaIVA”: “15”,
“EB_RigheOrdiniClienti.ref_SottRicavo”: “540”
}]
}]
}
Questo invece quello con cui lo cancello:
{
“jsonrpc”: “2.0”,
“id”: “0”,
“method”: “delete_record”,
“params”: [“5d3125e0e6255a27bb0b66750d050e9f”, “EB_OrdiniClienti”, “24411”]
}
Per cortesia può aiutarmi a capire l’errore ed eventualmente come intervenire?
( faccio presente che l’errore viene restituito anche sugli ordini fatti prima delle modifiche. Su Konga si cancellano correttamente )
grazie
Enzo Callegari
dimenticavo,
solo quando cancello un ordine per gli altri archivi sembra tutto ok….
Buon giorno,
proprio come suggerito da lei dipendeva da quello.
Cosa strana è che fino a prima delle modifiche via query e la cancellazione di una delle due aziende, si cancellavano senza passare quel parametro….
In ogni caso l’importante che funzioni ora!!
Grazie
Enzo Callegari
Buon giorno sig. Toso,
ho la necessità di modificare con un json la tabella EB_DatiCliForAzienda ho provato con:
{
“jsonrpc”: “2.0”,
“id”: “0”,
“method”: “update_record”,
“params”: [“096cc4ac079f548b9baf581697c85559”, “EB_DatiCliForAzienda”, “4405”, “null”, “00000001”, “”, {
“EB_DatiCliForAzienda.code_BancaAzienda”: “00003”
}]
}
ma non prende la modifica…..( ho provato anche con ref_BancaAzienda ma non cambia )
Questo invece prende correttamente la modifica:
{
“jsonrpc”: “2.0”,
“id”: “0”,
“method”: “update_record”,
“params”: [“096cc4ac079f548b9baf581697c85559”, “EB_DatiCliForAzienda”, “4405”, “null”, “00000001”, “”, {
“EB_DatiCliForAzienda.Fido”: “100”
}]
}
Se invio questo:
{
“jsonrpc”: “2.0”,
“id”: “0”,
“method”: “update_record”,
“params”: [“096cc4ac079f548b9baf581697c85559”, “EB_DatiCliForAzienda”, “4405”, “null”, “00000001”, “”, {
“EB_DatiCliForAzienda.Fido”: “100”
“EB_DatiCliForAzienda.code_BancaAzienda”: “00003”
}]
}
viene modificato solo il campo EB_DatiCliForAzienda.Fido
Per cortesia mi può aiutare a capire l’errore?
Grazie
Enzo Callegari
Questo comportamento è causato da un errore: Konga server attualmente non esegue i “look-up” per la tabella “EB_DatiCliForAzienda”, di conseguenza con la versione attuale del programma occorre utilizzare il nome campo “EB_DatiCliForAzienda.ref_BancaAzienda” indicando direttamente l’id della banca. Questo errore è già stato corretto nella versione 1.4.5 “stable”, quindi la correzione sarà presente nella versione pubblica 1.4.5 che sarà rilasciata a breve. Grazie per la segnalazione.
Grazie
Enzo Callegari
Gentile Fabrizio,
sto’ provando a inserire ordini e nuovi clienti via web service, tutto fila liscio. Ho solo un inconveniente : immettendo, in un ordine, solo i dati “obbligatori” minimi, mi ritrovo delle linee articoli differenti da come le ritrovo solitamente quando inserisco direttamente l’ordine in Konga. Esempio, vedo nella linea articolo il codice ma non il nome prodotto a esso correlato. Sto’ sbagliando qualcosa io ?
Grazie in anticipo, Alex
No, è normale: la descrizione nelle righe degli ordini deve essere indicata utilizzando il campo EB_RigheOrdiniClienti.DescArticolo. La descrizione proposta in automatico è una caratteristica del Konga Client, non del Konga Server; inoltre la descrizione presente nelle righe dei documenti può anche essere diversa da quella abbinata all’articolo.
Sostanzialmente, quelli che sono i campi che si compilano in “lookup” quando uso il client devo scriverli io sempre via web service.
Grazie per la celere risposta, un saluto
Alex
Sì, corretto.