Documentazione a supporto degli Scenari d'Uso
Per supportare i vari scenari d'uso gestiti, vengono forniti alcuni casi d'uso come esempi.
Nota: Sebbene l'utilizzo dei servizi consenta implementazioni diverse da quelle specificate, si ricorda che le funzionalità supportate sono quelle descritte nei Casi d'Uso indicati.
General Master Data
Default campo ditta nei data transfer object (DTO)
Nelle richieste POST per l'inserimento di nuovi record o documenti, è possibile specificare il campo 'ditta' o 'dittaCg18'.
Un esempio pratico: Si desidera inserire un documento di tipo C-DDT per il cliente 1 e per la ditta 1000.
Fino alla versione 202403000, il campo 'ditta' doveva essere definito per ogni proprietà del body, quindi era necessario popolare il campo 'ditta' o 'dittaCg18' come mostrato nell'esempio JSON seguente:
{
"ditta": '1000',
"valutaCg08": "EURO",
"anagraficaDocumentoDitta": {
"dittaCg18": '1000',
"codDocumMg36": "C-DDT",
"indStaperMg36": 1.0
},
"customerSupplierMG": {
"dittaCg18": '1000',
"tipocfCg40": 1,
"cliFor": 1
},
"sezdoc": "00",
"storageWH": {
"dittaCg18": '1000',
"codDep": "00"
},
"righe": [
{
"ditta": '1000',
"progrRiga": 1.0,
"codartMg66": "ART001",
"descart": "Descrizione articolo",
"qta1": 15.000
}
]
}
Dalla versione 202501000 è stata introdotta una logica predefinita per il campo ditta negli oggetti Data Transfer Object (DTO).
Se il valore del campo ditta dell'entità "root" non è fornito o è nullo, esso viene automaticamente popolato con il codice ditta recuperato dalla sessione utente corrente (parametro company). Questa operazione si propaga a tutte le entità associate, sia esterne che interne.
Di conseguenza, l'utente utilizza sempre la stessa richiesta:
{{webapi_base_url}}/api/v1/{{scope}}/MG/Documento?company=1000
Ma nel corpo della richiesta non è più necessario definire il campo ditta o dittaCg18, come mostrato nel seguente esempio JSON:
{
"valutaCg08": "EURO",
"anagraficaDocumentoDitta": {
"codDocumMg36": "C-DDT",
"indStaperMg36": 1.0
},
"customerSupplierMG": {
"tipocfCg40": 1,
"cliFor": 1
},
"sezdoc": "00",
"storageWH": {
"codDep": "00"
},
"righe": [
{
"progrRiga": 1.0,
"codartMg66": "ART001",
"descart": "Descrizione articolo",
"qta1": 15.000
}
]
}
Se il campo 'ditta' viene definito in una proprietà del body, deve essere obbligatoriamente definito in tutte le proprietà che compongono il body.
Inserimento minimale di una anagrafica generale
Qui di seguito è riportato l'esempio di inserimento di un'anagrafica generale come Persona Fisica, con i dati minimi:
{
"codfiscale": "MRARSS13S08H501H",
"partiva": null,
"flgAnagval": 1.0,
"ragSoAnag": "Mario Rossi & C",
"statofiscCg07" : 86.0, // Country ITALY
"sesso": 0.0, // 0 = M 1 = F
"addresses": [
{
"cap": 47838,
"citta": "Rimini",
"numciv": "12",
"via": "Draghi 9",
"addressesType": [
{
"tipo": 1 // Business location
}
],
"statoEst": {
"codice": 86.0 // Country ITALY
}
}
]
}
Inserimento minimale di un Cliente/Fornitore
Per inserire un cliente o un fornitore, è necessario aver precedentemente inserito i dati anagrafici comuni e, nel caso dell’inserimento di un cliente, indicare il codice corrispondente dei dati anagrafici comuni, come mostrato nell’esempio seguente:
{
"flgAttivo": 1.0,
"tipocf": 0.0,
"generalMasterDataCO": {
"codice": 774
},
"paymentTermCO": {
"codPag": "301",
"descPag": "NR.01 RD A VISTA",
"id": 50
},
"extensionData": []
}
Contabilità
Movimenti di Prima Nota
La risorsa "GLEntryFI" può essere utilizzata per inserire movimenti di prima nota in TSE. Anche se la stessa risorsa è utilizzabile per l'inserimento di qualsiasi tipo di movimento di prima nota, lo scenario applicativo attualmente supportato sul cloud è quello dell'inserimento di una Fattura di Vendita Cliente con Scadenze.
Per quanto riguardo lo Swagger, fare riferimento al seguente servizio FI / GLEntryFI / multiplecreatejob
Gli scenari di Prima Nota, vengono resi disponibili direttamente nello swagger all'interno della chiamata POST (Create) e nella POST del multiplecreatejob del modulo IntegrationFI\GLEntryFI, alcuni esempi:
Tramite il "Try it out" sarà possibile eseguire automaticamente la chiamata, sostituendo i segnaposti indicati negli esempi con i relativi dati opportuni.
Esempi disponibili multiplecreatejob:
- Default (complete): riporta il body completo di chiamata;
- Supplier Invoice: fattura di acquisto fornitore
- Supplier Invoice Payment: pagamento fattura di acquisto fornitore
- Customer Invoice with due dates and deposit: fattura di vendita cliente con acconto e scadenze
- Supplier Invoice reverse charge: fattura di acquisto in reverse charge;
- Supplier Invoice/Payment
- Movimento IVA fornitore (causale 31) senza scadenze;
1 contropartita con codice IVA (22%) su conto acquisto
- Pagamento fattura fornitore
- Causale pagata fattura (100) con numero documento riferimento fornitore;
- 1 riga Fornitore;
- 1 riga Contropartita Banca
- Customer Invoice with due dates and deposit
- Movimento IVA cliente (causale 1) con 2 conti e 2 assoggettamenti IVA 22% con storno acconto
- 1 contropartita con codice IVA (22%) su conto ricavi
- 1 contropartita con codice IVA (22%) su conto anticipi cliente
- 3 scadenze (30/60/90)
La riga di acconto presente nella fattura è immessa come riga a valore con importo negativo.
- Supplier Invoice reverse charge
- Movimento IVA fornitore italiano (ex. causale 91) con codice iva di tipo reverse charge
- 1 contropartita con codice IVA di tipo reverse charge
- 1 scadenza di tipo rimessa diretta
NB: l'esempio allegato utilizza il codice causale 91 Fattura acquisto art.17 c.5 DPR 633/72 con un fornitore italiano, il medesimo esempio è valido per tute le causale in reverse charge:
51 Fattura acquisto intracomunitaria (fornitore Cee) 96 Fattura acq.sogg. non resid.(art.17 c.3) (fornitore Extracee) 41 Fattura acquisto RSM (fornitore San Marino) 93 Fattura acquisto art.17-ter DPR 633/72 (fornitore splitpayment)
con il seguente dettaglio di codice in chiamata:
{
"data": {
"items": [
{
"vatReverseIncoporated": true,
"recoverReverseChargeIfNotDefined": true,
"externalRif": "60",
"ExternalInfo": {},
....
}
]
}
}
Riportiamo inoltre, il seguente dettaglio di codice relativo a:
- Movimento IVA fornitore con ritenuta d'acconto
"WtPurchases": [
{
"codTribrp": "",
"codTributo": "1040",
"contcditta": 0.0,
"contcperc": 0.0,
"contribint": 0.0,
"datareg": "{{dataReg}}",
"dittaCg18": {{defaultCompany}},
"enasazienda": 0.0,
"flgSegno": 0,
"imponibilera": 100.00,
"imponibilerp": 100.00,
"importoalrit": 0.0,
"importora": 20.00,
"ind770": 1,
"percra": 20.0,
"percrp": 0.0,
"provvnonsog": 0.0,
"rimborsi": 0.00,
"generalMasterDataCODTO": {
"codice": {{idAnagProfessionista}}
},
"sectionalMasterDataCODTO": {
"dittaCg18": {{defaultCompany}},
"sezionale": "00"
},
"wtCodeCODTO": {
"codice": "101 "
}
}
]
Esempi disponibili in GLEntryFI:
- Default (complete): riporta il body completo di chiamata;
- Accounting transfer: giroconto contabile.
- Accounting transfer
-
Movimento NON IVA (causale 109)
- 1 riga Fornitore (debiti v/fornitori);
- 1 riga conto transitorio;
- 1 riga contropartita Clienti
Proprietà tipoDoc - tipo documento per garantire la congruenza nella protocollazione dei movimenti IVA si consiglia di passare tra i valori di testata la proprietà tipoDoc (tipo documento) valorizzandolo in modo coerente alla causale iva di riferimento
di seguito i valori da passare in funzione della causale di riferimento
-
ACQUISTI Causaleiva in (31, 41, 51, 71, 91, 93, 96) -> tipoDoc = 2 Causaleiva = 32 -> tipoDoc = 1 Causaleiva = 33 -> tipoDoc =14 Causaleiva in (35, 42, 52, 92, 94, 97) ->tipoDoc = 5 Causaleiva = 37 -> tipoDoc =7 Causaleiva = 39 -> tipoDoc =9
-
VENDITE Causaleiva in (1, 61, 281) -> tipoDoc =1 Causaleiva = 2 -> tipoDoc = 13 Causaleiva in (5, 63, 285) ->tipoDoc = 4 Causaleiva = 7 ->tipoDoc = 6 Causaleiva = 9 -> tipoDoc =8 Causaleiva = 62 -> tipoDoc =10
Creazione righe IVA
Per ogni movimento di prima nota è possibile specificare tramite il parametro "autoVatRow" la possibilità di calcolare o meno le righe in automatico (true) o passarle dall'esterno (false). Di default il parametro è settato a false.
Creazione scadenze
Al momento non vengono misurati tramite le condizioni di pagamento e quindi devono essere sempre passate. Attenzione: l'importo delle rate scadenze e della relativa iva, deve quadrare con il totale documento.
Framework
Dlevel e Dlevelkey
Tramite il servizio DlevelEntityName, è possibile recuperare un elenco di informazioni relative alle entità correlate, partendo da un DTO specifico, in modo da poter comprendere i nomi delle Entità (internalNameDeserialization e externalNameDeserialization) per poi valorizzare la proprietà dlevel richiesta in tutte le GET standard.
Il deserialization level è una sintassi che descrive quali rami del grafo, che costituisce l'aggregato, devono essere caricati in una lettura. Sintassi:
[] le parentesi quadre identificano le relazioni interne
le parentesi graffe identificano una relazione esterna
- identifica tutti i nomi di relazioni in quel contesto
Ad esempio, dato un 'DTO name:DocumentoTestataMGDTO si può eseguire la seguente chiamata:
GET {{webapi_base_url}}/api/v1/{{scope}}/FW/DlevelEntityName/DocumentoTestataMGDTO?company={{defaultCompany}}
che riporterà nella response le seguenti informazioni (riporto parziale della response):
[
{
"internalNameDeserialization": "DocumentoDatiAccompagnamentoMG",
"externalNameDeserialization": null,
"relatedDTOEntityName": "DocumentoDatiAccompagnamentoMGDTO",
"relatedDTOPropertyName": "DocumentoDatiAccompagnamentoMG"
},
{
"internalNameDeserialization": "RigheDocumento",
"externalNameDeserialization": null,
"relatedDTOEntityName": "DocumentoRigaMGDTO",
"relatedDTOPropertyName": "Righe"
},
{
"internalNameDeserialization": "DocumentoTestataAgentiMG",
"externalNameDeserialization": null,
"relatedDTOEntityName": "DocumentoTestataAgentiMGDTO",
"relatedDTOPropertyName": "DocumentoTestataAgentiMG"
},
]
Se si desidera visualizzare le informazioni relative all’entità interna 'RigheDocumento', si esegue la stessa chiamata indicando il EntityDTOName:DocumentoRigaMGDTO, per cui:
GET {{webapi_base_url}}/api/v1/{{scope}}/FW/DlevelEntityName/DocumentoRigaMGDTO?company={{defaultCompany}}
che riporterà nella response tutte le 'internalNameDeserialization' e le 'externalNameDeserialization' per il DTO specificato (riporto parziale della response):
[
{
"internalNameDeserialization": "DocumentoCorpoCOINMG",
"externalNameDeserialization": null,
"relatedDTOEntityName": "DocumentoRigaCOINMGDTO",
"relatedDTOPropertyName": "DocumentoRigaCOINMG"
},
{
"internalNameDeserialization": null,
"externalNameDeserialization": "CodIvaCO",
"relatedDTOEntityName": "VatCodeCODTO",
"relatedDTOPropertyName": "CodIva"
},
{
"internalNameDeserialization": "DocumentoCorpoProgettiMG",
"externalNameDeserialization": null,
"relatedDTOEntityName": "DocumentoRigaProgettiMGDTO",
"relatedDTOPropertyName": "DocumentoRigaProgettiMG"
},
{
"internalNameDeserialization": "RigaRiferimenti",
"externalNameDeserialization": null,
"relatedDTOEntityName": "DocumentoRigaRiferimentoMGDTO",
"relatedDTOPropertyName": "RigaRiferimenti"
},
{
"internalNameDeserialization": null,
"externalNameDeserialization": "OfficeCO",
"relatedDTOEntityName": "OfficeCODTO",
"relatedDTOPropertyName": "OfficeCO"
}
]
A questo punto si può eseguire la chiamata GET di un documento specifico e recuperare solo le informazioni desiderate, limitando ad esempio la chiamata GET :
all'entità esterna codici iva da result DocumentoRigaMGDTO ("externalNameDeserialization": "CodIvaCO")
all'entità interna progetti da result DocumentoRigaMGDTO ("internalNameDeserialization": "DocumentoCorpoProgettiMG")
all'entità esterna ClienteFornitore da result DocumentoTestataMGDTO ("externalNameDeserialization": "CustomerSupplierMG")
all'entità esterna AnagraficaDocumentoDitta da result DocumentoTestataMGDTO ("externalNameDeserialization": "CompanyDocumentMasterDataMG")
In questo caso la sintassi corretta si traduce in "[RigheDocumento[CodIvaCO][DocumentoCorpoProgettiMG]][CustomerSupplierMG],CompanyDocumentMasterDataMG}" e deve essere convertita nel formato URL-encoded per aggiungerlo come valore del parametro dlevel.
Quindi si esegue la chiamata GET del documento, il cui numreg corrisponde a 202500000024 e si valorizza nella chiamata anche il parametro dlevel=%5BRigheDocumento%7BCodIvaCO%2COfficeCO%7D%5BDocumentoCorpoProgettiMG%5D%5D%7BCustomerSupplierMG%2C%20CompanyDocumentMasterDataMG%7D: In questo modo nella response saranno riportati solo i valori dell'entità sopra descritte nell'esempio.
Si è reso disponibile anche il servizio DlevelKey, con cui è possibile avere un elenco di tutte le serializzazioni predefinite da usare nella proprietà dlevelkey e presente in tutte le chiamte GET standard del DTOname indicato come parametro nella chiamata.
Ad esempio, dato come 'DTO name' CustomerSupplierCODTO, tramite il servizio DlevelKey, se si esegue la seguente chiamata:
GET {{webapi_base_url}}/api/v1/{{scope}}/FW/DlevelEntityName/CustomerSupplierCODTO?company={{defaultCompany}}
e nella response saranno riportate alcune informazioni, tra cui il parametro 'dlevelkey':
[
{
"entityDTOName": "CustomerSupplierCODTO",
"dLevelKeyName": "DL_CustomerSupplierCO_GeneralMasterDataCO",
"deserializationLevel": "{GeneralMasterDataCO}"
},
{
"entityDTOName": "CustomerSupplierCODTO",
"dLevelKeyName": "DL_GLEntryFI_AnaGen",
"deserializationLevel": "{GeneralMasterDataCO}"
},
{
"entityDTOName": "CustomerSupplierCODTO",
"dLevelKeyName": "DL_IntrastatDataHeaderIN_AnaGen",
"deserializationLevel": "{GeneralMasterDataCO}"
}
]
At this point, for example, you execute a GET call for CustomerSupplierCO, with idclifor=5, and also set the dlevelkey parameter to DL_CustomerSupplierCO_GeneralMasterDataCO:
GET {{webapi_base_url}}/api/v1/{{scope}}/CO/CustomerSupplierCO/5?company={{defaultCompany}}
In this case, the response will display the properties of the root 'CustomerSupplier' and the entity {GeneralMasterDataCO} as shown in the JSON below:
{
"gmdUpdateAdditionalParams": null,
"clifor": 2.0,
"codAbiCg12": null,
"codCabCg13": null,
"codiceCg28": null,
"contoCg24": null,
"contorCg24": null,
"contratto": null,
"datavaliva": null,
"dittaCg18": 1000.0,
"flgArt62": 0,
"flgAttivo": 1.0,
"flgCointestati": 0.0,
"flgIntercompany": 0.0,
"ggscadfix": null,
"gruppoCg10": 80.0,
"guid": "a4630426-554a-4c95-be8b-4bb9bf52a0d2",
"idclifor": 5,
"idmediaCg99": null,
"indElenchimov3000": 99,
"intermedioCg40": null,
"lastchange": "2024-12-04T11:40:36.383",
"progREf08": null,
"tipocf": 1.0,
"idExtendedAttributeEntity": 3,
"idExtendedAttributeSubEntity": 4,
"generalMasterDataCO": {
"alias": null,
"auidAu04": null,
"cap": "20121 ",
"capcor": null,
"capfisc": "20121 ",
"cellnum": null,
"citta": "MILANO",
"cittacor": null,
"cittafisc": "MILANO",
"codfiscale": "00000452151",
"codice": 4,
"codiceCg07": 86.0,
"codiceCg15": null,
"codiceCgc0": null,
"codicecorCg07": null,
"codiceident": null,
"codicesfed": null,
"codrichiamo": null,
"cognome": null,
"comfisCg01": "F205",
"comnascita": null,
"comnascitaCg01": null,
"datanascita": null,
"datavalid": null,
"dtfinepec": null,
"dtiniziopec": null,
"faxnum": null,
"flgAnagval": 1.0,
"flgFattpa": 0,
"flgNoblacklist": 0.0,
"flgOmonimo": 0.0,
"flgPrsfis": 0.0,
"idmediaCg99": null,
"indemail": null,
"indFiscale": "Contrada Fattoria di Greg 1",
"indFiscaleEX": null,
"indirCor": null,
"indirCorEX": null,
"indirizzo": "Contrada Fattoria di Greg 1",
"indirizzoEX": null,
"indsoggrit": 0.0,
"indweb": null,
"lastchange": "2024-12-04T11:40:36.357",
"nome": null,
"partitaIVA": "00000452151",
"partiva": "00000452151",
"partivaEst": null,
"prov": "MI",
"provcor": null,
"provfisc": "MI",
"provnascita": null,
"ragSoAnag": "Greg",
"ragsoanagex": null,
"ragsocor": null,
"ragsocorex": null,
"ragsofisc": "Greg",
"ragsofiscex": null,
"rapazestCg16": null,
"sesso": 0.0,
"statofed": null,
"statofedfisc": null,
"statofiscCg07": 86.0,
"statonascitaCg07": null,
"tel1num": null,
"tel2num": null,
"idExtendedAttributeEntity": 1,
"idExtendedAttributeSubEntity": 2,
"extensionData": [],
"additionalData": {}
},
"extensionData": [],
"additionalData": {}
}
Metadata DTO
E' il servizio che, dato un EntityDTO di riferimento, produce una lista che contiene la mappatura del DTO. Per fare le analisi sulla struttura del DTO, sono forniti i seguenti strumenti:
- Servizio GET - FW/MetadataDTO/EntityDTOname
È stato introdotto un nuovo servizio GET nel modulo IntegrationInfrastructure per la risorsa MetadataDTO. Questo servizio richiede come parametro un EntityDtoName e consente di visualizzare la struttura dell'oggetto, comprese tutte le sue proprietà e le relazioni internal ed external.
Nella response sono visualizzate anche tutte le relazioni dell'entità DTO nel seguente modo:
-
Relazioni interne all’entità root o padre (che appartengono all’entità di partenza e vengono memorizzate dal CRUD nella stessa transazione)
-
Relazioni esterne all’entità (utilizzate per la semplice decodifica dei dati presenti su altre entità)
Ad esempio se si desidera visualizzare la struttura di DocumentoTestataMGDTO, si deve eseguire la seguente chiamata:
GET {{webapi_base_url}}/api/v1/{{scope}}/FW/MetadataDTO/CustomerSupplierCODTO?withdescriptions=true
Il servizio riporta in formato JSON la struttura dell’EntityDTOName. Qui di seguito è riportato solo una parte del json della response:
{
"name": "Documento",
"type": "DocumentoTestataMGDTO",
"entityName": "DocumentoTestataMG",
"properties": [
{
"propertyName": "bancaCg12",
"propertyType": "Decimal",
"isKey": false,
"mandatory": false,
"entityPropertyName": "BancaCg12",
"entityPropertyType": "System.Decimal",
"rangeValue": null,
"description": null,
"shortDescription": null,
"maxLength": 5,
"scale": 0
},
{
"propertyName": "cambio",
"propertyType": "Decimal",
"isKey": false,
"mandatory": false,
"entityPropertyName": "Cambio",
"entityPropertyType": "System.Decimal",
"rangeValue": null,
"description": null,
"shortDescription": null,
"maxLength": 12,
"scale": 6
},
{
"propertyName": "cauprestCg15",
"propertyType": "String",
"isKey": false,
"mandatory": false,
"entityPropertyName": "CauprestCg15",
"entityPropertyType": "System.String",
"rangeValue": null,
"description": null,
"shortDescription": null,
"maxLength": 4,
"scale": null
},
{
"propertyName": "causmagMg51",
"propertyType": "Decimal",
"isKey": false,
"mandatory": false,
"entityPropertyName": "CausmagMg51",
"entityPropertyType": "System.Decimal",
"rangeValue": null,
"description": null,
"shortDescription": null,
"maxLength": 4,
"scale": 0
},
]
}
Nella response sono riportate tutte le proprietà che compongono 'DocumentoTestataMGDTO', ma sono anche riportate tutte le relazioni, legate a 'DocumentoTestataMGDTO'. A titolo di esempio qui di seguito è riportata la relationName: "righe" :
"relationName": "righe",
"relationType": "DocumentoRigaMGDTO[]",
"entityRelationName": "RigheDocumento",
"entityRelationType": "DocumentoCorpoMG",
"multiplicity": "1:*",
"isExternal": false,
"meta": {
"name": "",
"type": "DocumentoRigaMGDTO",
"entityName": "DocumentoCorpoMG",
"properties": [
{
"propertyName": "alivacompCg28",
"propertyType": "String",
"isKey": false,
"mandatory": false,
"entityPropertyName": "AlivacompCg28",
"entityPropertyType": "System.String",
"rangeValue": null,
"description": null,
"shortDescription": null,
"maxLength": 4,
"scale": null
},
]
}
In questo caso si può eseguire una nuova chiamata GET su DocumentoRigaMGDTO per prendere visione di tutte le proprietà e di tutte le relazioni per il DocumentoRigaMGDTO, e così via.
Inoltre è anche possibile utilizzare alcuni parametri aggiuntivi: il Parametro withdescriptions=true che serve per visualizzare le descrizioni nelle proprietà e il parametro Headers: Accept=application/xml per avere un result in formato xml.
- Lookup Service - FW/lookup/MetadataDTOView
È stato introdotto un nuovo servizio che permette di vedere,tramite lookup, SOLO se le proprietà sono esposte sul DTO (sono visualizzate solo le righe con PropertyDTOName NOT NULL).
Si deve eseguire la seguente chiamata:
POST {{webapi_base_url}}/api/v1/{{scope}}/FW/lookup/MetadataDTOView?metadata=true&company={{defaultCompany}}&_op=search
Con tale lookup è possibile eseguire delle selezioni, ad esempio utilizzando il nome della tabella oppure il nome della colonna, per ricavare il nome dell’entità collegata.
Partendo da 'EntityName' presa in considerazione nel precedente esempio 'DocumentoTestataMG', si può eseguire la chiamata POST con il seguente body:
{
"filters": {
"items": [
{
"operator": 0,
"comparer": 0,
"propertyName": "EntityName",
"value": "DocumentoTestataMG"
}
],
"orderingProperties": {
"EntityName": 0
}
},
"pageSize": 0,
"pageNumber": 0
}
e nella response saranno riportate le proprietà esposte per il DTO preso in esame.
Oppure si può eseguire una selezione partendo dal nome della tabella. Ad esempio indicando come TableName=CG44_CLIFOR, come qui di seguito riportato:
{
"filters": {
"items": [
{
"operator": 0,
"comparer": 0,
"propertyName": "TableName",
"value": "CG44_CLIFOR"
}
],
"orderingProperties": {
"EntityName": 0
}
},
"pageSize": 0,
"pageNumber": 0
}
nella response saranno riportate tutte le proprietà esposte. Qui di seguito è riportato solo una parte del json della response a titolo di esempio:
{
"name": "MetadataDTOView",
"resources": [],
"pageNumber": 0,
"pageSize": 77,
"data": [
[
"CustomerSupplierCO",
"CustomerSupplierCODTO",
"Property",
null,
null,
"Tipocf",
"Tipocf",
"Tipo Cliente / Fornitore",
null,
"CG44_CLIFOR",
"CG44_TIPOCF",
"decimal",
1,
true,
null,
"0= Cliente - 1= Fornitore",
false
],
],
}
Oppure è anche possibile effettuare un'ulteriore selezione tramite il nome della colonna, per cui indicando FieldName=CG44_TIPOCF:
{
"filters": {
"items": [
{
"operator": 0,
"comparer": 0,
"propertyName": "FieldName",
"value": "CG44_TIPOCF"
}
],
"orderingProperties": {
"EntityName": 0
}
},
"pageSize": 0,
"pageNumber": 0
}
nella response saranno riportate tutte le proprietà esposte dove è utilizzato il suddetto FieldName:
{
"name": "MetadataDTOView",
"resources": [],
"pageNumber": 0,
"pageSize": 4,
"data": [
[
"CustomerSupplierCO",
"CustomerSupplierCODTO",
"Property",
null,
null,
"Tipocf",
"Tipocf",
"Tipo Cliente / Fornitore",
null,
"CG44_CLIFOR",
"CG44_TIPOCF",
"decimal",
1,
true,
null,
"0= Cliente - 1= Fornitore",
false
],
[
"CustomerSupplierFI",
"CustomerSupplierFIDTO",
"Property",
null,
null,
"Tipocf",
"Tipocf",
"Tipo Cliente / Fornitore",
null,
"CG44_CLIFOR",
"CG44_TIPOCF",
"decimal",
1,
true,
null,
"",
false
],
]
}
- Query Descriptor on FW/Lookup service
Nell'elenco delle lookup disponibili, richiamabile mediante il servizio Get di FWK "FW/Lookup", sono stati definiti i parametri obbligatory da indicare nella SearchDTO.
Ad esempio: il servizio FW/Lookup ci restituisce la Lookup relativa all'entità ProjectWH
{
"lookupName": "ItemProjectWH",
"description": "ItemProjectWH",
"href": "/api/v1/LDB_TESTWAPILEG/WH/Lookup/ItemProjectWH",
"typeQuery": "QueryDescriptor",
"parametersQueryDescriptor": "ProjectCode"
}
Per questa entità i parametri devono essere riporati nel modo di seguito indicato:
{
"parameters": {
"ProjectCode": "1"
}
}
License Service
Dalla versione 2025002000 è stato introdotto il nuovo servizio LicenseFW che sostituisce il precedente FW/Licenze reso obsoleto. L'unica azione possibile attualmente è la GET per ottenere tutte le informazioni riguardo un id di licenza passato tramite parametro:
GET {{webapi_base_url}}/{{api}}/v1/{{scope}}/FW/LicenseFW/info/{{idLicenza}}?company={{defaultCompany}}
Un esempio di json di risposta è il seguente:
{
"codLicenza": 1055,
"numLicenza": "XXYYZZW0",
"keyAttivazione": "9gTE8Rwo",
"dataRilascio": "2025-04-14T00:00:00",
"partitaIvaCliente": "11281128112",
"partitaIvaRivenditore": "01030103010",
"licenzaDemo": 0,
"numeroPostazioni": 2,
"quantita": 0,
"isValid": true,
"extensionData": [],
"additionalData": {},
"pluginData": {}
}
Infrastructure
Servizi di Autenticazione
Per accedere a tutti i servizi disponibili, l'utente deve ottenere un token di autenticazione, che può essere aggiornato e revocato. Di seguito sono riportati esempi di azioni per gestire questo servizio.
Per ottenere un nuovo token di accesso, è sufficiente effettuare la seguente chiamata:
POST {{webapi_base_url}}/{{api}}/v1/auth/token
Come response, se tutto va a buon fine, riceverai un corpo (body) come il seguente:
{
"access_token": "xxx ... yyy123zzz",
"expires_int": 28800,
"scope": "test_scope",
"token_type": "Bearer",
"refresh_token": "a1b2c3... z9w8y7"
}
Nota che, oltre al token di accesso, è necessario salvare anche il token di aggiornamento, identificato dal parametro esplicativo refresh_token, che sarà necessario per le operazioni di rinnovo. Infatti, quando un token di accesso scade, è possibile rinnovarlo con la seguente chiamata:
POST {{webapi_base_url}}/{{api}}/v1/auth/token/refresh
È necessario includere nella richiesta un corpo (body) contenente entrambi i token obbligatori, access e refresh, con gli stessi valori ottenuti al momento della richiesta, e il token di aggiornamento NON DEVE ESSERE SCADUTO.
{
"access_token": "xxx ... yyy123zzz",
"refresh_token": "a1b2c3... z9w8y7"
}
Come risposta, riceverai un "body" con la stessa struttura di quello per la generazione del token, ma con valori ovviamente diversi, che dovranno essere salvati per le future operazioni di rinnovo.
Per revocare un token di accesso non ancora scaduto, è possibile effettuare la seguente chiamata:
POST {{webapi_base_url}}/{{api}}/v1/auth/token/revoke
Includendo nel "body" della richiesta il singolo parametro "token", che si riferisce al token assegnato all'utente che si desidera revocare.
Gestioni non supportate
Qui di seguito un elenco di gestioni particolari attualmente non supportate in inserimento di un documento via WebAPI:
- Controllo rischio
- Esplosione schede multiple articoli