Campo per codice SDI nella Entity Cliente

[mauriziofonte]

Buongiorno,

vorrei sapere se è presente il campo per l'assegnazione del codice SDI durante la creazione di una fattura.

Vecchio payload della V1:

'autocompila_anagrafica' => false,
'salva_anagrafica' => false,
'extra_anagrafica' => [
	'mail' => $user->email,
	'tel' => $billingAddress->phone ?? '',
],
'PA' => true,
'PA_tipo_cliente' => 'B2B',
'PA_data' => date('d/m/Y'),
'PA_codice' => $billingAddress->sdi_code,
'PA_pec' => $billingAddress->pec_mail,
'PA_modalita_pagamento' => 'MP08',

Piuù in generale, come si traducono i campi PA_codice, PA_pec, PA_data, PA_tipo_cliente e PA_modalita_pagamento nella nuova struttura delle richieste?

[emajo]

Ciao @mauriziofonte i dati PA_codice, PA_pec, PA_data, PA_tipo_cliente sono stati spostati dentro la risorsa client, modalità pagamento invece è diventato ei_data.payment_method all'interno del documento.

Resto a disposizione per ulteriori chiarimenti,
Emanuele

[mauriziofonte]

Ciao @emajo , sempre in relazione al porting dalla V1, abbiamo optato per la soluzione ad autenticazione Manuale, visto che è una routine in PHP ad occuparsi della fatturazione, e non era necessario tutto il discorso OAuth per l'implementazione.

Riscontro un problema, avendo configurato tutto come da documentazione, le richieste a c/{company}/issued_documents sollevano questo errore:

{"error":"unauthorized","error_description":"The given user is not authorized to use this application."}")

E' un problema di Scope dell'applicazione?

[valmoz]

Ciao @mauriziofonte ti pregherei di creare diverse discussions se le tue domande non sono relative allo stesso problema. Ciò permetterà una ricerca più semplice da parte degli altri utenti delle risposte precedenti.

Inizio rispondendo alla prima domanda.
Il campo Entity può aver tipo Client o Supplier. Abbiamo rappresentato questa possibilità come Entity nelle API perché i due condividono la maggior parte dei dettagli.
Per quanto riguarda il salvataggio automatico dei clienti in anagrafica, abbiamo già risposto qui.

Per quanto riguarda l'autenticazione manuale, non c'è problema. Suggeriamo sempre di utilizzare OAuth2 quando possibile, ma il token manuale è una delle possibilità a vostra disposizione. Vi ricordo solo di gestire eventuali errori legati alla creazione del token da parte dei vostri utenti (ad esempio mancanza di scope).
Il problema in questione è relativo alla visibilità dell'applicazione. Per permettere a un utente di collegare un'app privata è necessario inserire il suo account Fatture in Cloud alla whitelist presente sulla pagina dell'applicazione stessa.

Grazie
Mauro

[valmoz]

Ciao @mauriziofonte sei riuscito a risolvere il problema?

Grazie
Mauro

[valmoz]

Ciao @mauriziofonte cambio lo stato della discussion a "risposto" per inattività.

Se necessario, potrai semplicemente rispondere alla discussione.

Grazie
Mauro

[mauriziofonte]

@valmoz dopo svariati tentativi siamo riusciti a capire che il problema di autenticazione {"error":"unauthorized","error_description":"The given user is not authorized to use this application."}") era relativo ad un campo email mancante sul pannello di Admin di Fatture in Cloud.

Inoltre, abbiamo deciso di utilizzare la SDK ufficiale fattureincloud/fattureincloud-php-sdk per essere certi che le strutture dati inviate a FIC siano consone a quanto le API si aspettano.