[RFC] richiesta chiarimenti nuovo modello 3

[CandeAnn]

*Buongiorno, vi chiedo alcuni puntuali chiarimenti relativi alle SANP 2.4:

1. nella RT ricevuta tramite paSentRT, il valore receiptID corrisponde a IdentificativoUnivocoRiscossione contenuto adesso nella RT ricevuta con paaInviaRT. Corretto?
2. Se il punto 1. è corretto, nelle SANP 2.4 al par 11.2 sezione 3 è necessario correggere request-ID con receiptID
3. remittanceInformation corrisponde alla causale nel formato /RFB/IUV/100.00/TXT/xxxx ? corretto?
4. transferCategory corrisponde a datiSecificiRiscossione e quindi alla codifica della tassonomia incassi?
5. nella struttura “data” di getPaymentRes (e anche di paSendRT) cosa contiene l’elemento metadata ? Cosa sono le max 10 occorrenze di mapEntry? Non riesco a trovare niente nelle SANP

[lucagargiulo]

Ciao @CandeAnn, provo a riassumere quanto già emerso da altre RFC, che ti cito così puoi hai il giusto contesto. Ovviamente @gammam potrà essere più preciso se ho interpretato male

nella RT ricevuta tramite paSentRT, il valore receiptID corrisponde a IdentificativoUnivocoRiscossione contenuto adesso nella RT ricevuta con paaInviaRT. Corretto?

https://github.com/pagopa/pagopa-api/issues/95: il receiptId è l'identificativo univoco , in tutta la piattaforma, della ricevuta. Rispetto al passato vogliamo che ogni ricevuta sia unica per qualsiasi ente. Lo IUR nel flusso è il receiptId. Ogni ente è quindi in grado di identificare in maniera certa a ricevuta associata ad ogni voce del flusso utilizzando lo IUR + indiceDatiSingoloPagamento Il campo indiceDatiSingoloPagamento del flusso di rendicontazione è definito come un intero da 1 a 5. Pertanto non può essere univoco per l'ente, ma rimarrà univoco all'interno della ricevuta. Nella RT non essendoci tale indice bisognerà fare affidamento sull'ordinamento fisico degli item datiSingoloPagamento della RT https://github.com/pagopa/pagopa-api/issues/113: receiptId ha come valore il token di pagamento restituito all'interno dell'ActivatePayment ed utilizzato nella SendPaymentOutcome.

transferCategory corrisponde a datiSecificiRiscossione e quindi alla codifica della tassonomia incassi?

https://github.com/pagopa/pagopa-api/issues/93: Sia la paymentCategory che la transferCategory sono stringhe di testo di 140 caratteri: posso ipotizzare che che la transferCategory sia l’equivalente di datiSpecificiRiscossione e che contenga il codice tassonomico e opzionalmente i codici contabili relativi alla singola voce di pagamento? Si, corretto https://github.com/pagopa/pagopa-api/issues/111: nella transferCategory è corretto che venga inserito esclusivamente la tassonomia. Sembrerebbe quindi che la transferCategory sia destinata a contenere solo il codice della tassonomia, mentre per i dati contabili si dovrà individuare una collocazione in un campo separato ancora in fase di definizione a cura di un tavolo separato in cui si cercherà di concordare un formato standard che non so però se sia già stato convocato e cosa abbia eventualmente deciso.

nella struttura “data” di getPaymentRes (e anche di paSendRT) cosa contiene l’elemento metadata ? Cosa sono le max 10 occorrenze di mapEntry?

Dovrebbero essere delle coppie {chiave, valore} usate dall'EC per veicolare dati utili all'EC o ai suoi intermediari/partner, ma non utilizzati da pagoPA, un modo per consentire una qualche forma di estensibilità del messaggio come le AdditionalProperties nei messaggi Rest.

[CandeAnn]

@lucagargiulo le risposte contenute nel #93 e #111 sembrano un po' in contrasto: dalla #93 intendo che in tranferCategory si possa inserire la stringa del codice tassonomico e i dati opzionali preceduti dal secondo '/' (es: 9/0702101SP/XXX), Dal #111 sembra invece che sia corretto inserire solo al Tassonomia obbligatoria, quindi 9/0702101SP. Potrei avere un chiarimento?

[lucagargiulo]

Sono in contrasto in effetti, ma sono state fornite in tempi diversi, la seconda a seguito di una discussione relativa sulla riconciliazione dei pagamenti. Quindi potrebbe significare che PagoPA sta valutando l'ipotesi di tener separate le due informazioni introducendo un nuovo campo per i codici contabili, di cui vorrebbe definire il formato in modo standard (attività da parte di un tavolo di lavoro separato. Se così fosse per la transferCategory sarebbero necessari solo 9 caratteri. Aspettiamo cosa ci dice gamman in proposito.

[gammam]

started analysis in PAG-186

[gammam]

La ricevuta del pagamento avvenuto ( receipt ) ottenuta con tramite la sendRT è identificata univocamente dal campo receiptId il quale viene valorizzato con il _token di pagamento: assegnato al PSP durante l’operazione di pagamento. ( corregeremo la sezione delle SANP)

La remittanceInformation corrisponde all’attuale causale di versamento, così come specificato all’interno delle SACI.

la transferCategoy corrisponde alla tassonomia dei servizi, come da [pubblicazione](Tabella - Tassonomia dei servizi di incasso (05-05-2021).xlsx ). All’interno dell’RPT tale valore deve essere preceduto dal carattere 9/a causa del pattern del campo datiSpecificiRiscossione che inizialmente era stato specificato per utilizzare diverse codifiche del tributo.

Per retro-compatibilità il campo non specifica alcun pattern specifico, in modo tale che il medesimo valore utilizzato all’interno del campo dell’RPT non causi un blocco nel pagamento.

il campo metadata è stato introdotto per venire incontro alle esigenze emerse da diversi EC di veicolare informazioni diverse da quelle strettamente necessarie al pagamento.