Il paradosso dei servizi da attivare per l'avviso 1.4.3 del PNRR

Ciao a tutti, da poco mi sono imbattuto in un problema paradossale a cui, a detta del dipartimento, si sta cercando di mettere una pezza. Infatti, l’avviso del PNRR digitale 1.4.3 riguardante l’appIO finanzia l’attivazione e la pubblicazione di servizi ben definiti in un elenco. Il problema è che molti di questi servizi NON POSSONO essere attivati in quanto il loro nome cozza con le regole scritte nel manuale dei servizi IO . Pensiamo ad esempio al servizio “Asilo nido: iscrizione al servizio”. Tale titolo non può essere utilizzato per ben due motivi:

  • non deve contenere il mezzo o uno dei passaggi che vanno fatti per compierlo. Parole come “Pagamento”, “Scadenza”, “Comunicazione”, “Avviso”, “Informazioni”, “Controllo”, “Invito”, “Iscrizione”, “Concessione” e “Richiesta” sono passaggi che possono fare parte di qualsiasi servizio, e non vanno quindi inclusi all’interno del titolo.
  • dovrebbe evitare di contenere la parola “Servizio” .

Pertanto mi sono trovato con molti servizi scartati a cause di queste regole.
Cosa ulteriormente strana è che per alcuni enti tali servizi risultano già pubblicati e attivi senza problemi.
Vi chiedo cosa ne pensate e se vi siete imbattuti nella mia stessa problematica.

2 Mi Piace

I bandi PNRR mi fanno venire il mal di pancia… ma qui dovrebbe essere semplice da risolvere, nella pagina di manuale che citi fanno riferimento a un link ai servizi più diffusi, guarda come trattano la Tassa sui Rifiuti (TARI), si può prendere esempio da quello come servizio: Tassa sui rifiuti (TARI) - Manuale dei servizi dell'app IO P.es. “Mensa scolastica” come servizio e una serie di messaggi-sottoservizi in relazione al sub-adempimento.

Per chi è delgato è ancora peggio…
Noi abbiamo ricevuto l’incarico di creare dei servizi e la nomenclatura è scelta dall’ente ovviamente non da noi.

Ora PagoPA decide che la nomenclatura di questi servizi non è consona, la cosa mi starebbe anche bene se non per il fatto che questo ente ha già per altri servizi specifici con altri delegati gli stessi nomi (ovviamente per servizi diversi es TARI anzichè Canone Unico)! Assurdo!

Nelle motivazioni di non accettazione riscontro che il nome deve essere generico e che devo creare un unico servizio anzichè 8 servizi più specifici. Esempio: vorrebbero solo un servizio Canone Unico e non Canone Unico - Avviso Scadenza, Canone Unico - Sollecito etc etc.

Ora mi trovo a dover far da mediatore tra ente e PagoPa, dove noi abbiamo un contratto con delle tempistiche da rispettare e senza sapere quando e come saranno pubblicati i servizi.

Buongiorno,
in merito alla questione segnalo questa specifica nel manuale: " I servizi che vengono creati mediante chiamate API vengono creati e attivati in maniera istantanea, senza validazione da parte di PagoPA S.p.A."
mentre
I servizi creati tramite il back office di IO, invece, passano per un processo di revisione che consente di garantirne qualità. Questi, quindi, possono essere pubblicati solo se considerati validi, ovvero se rispettano i requisiti tecnici e di contenuto indicati in questo manuale operativo. "
Questo significa che se si riesce a pubblicare i servizi non da back-office ma da servizi esterni…i nomi e la tassonomia andranno sempre bene, questo giustificherebbe la presenza di servizi non conformi ma di fatto pubblicati.
Un saluto,

1 Mi Piace

una domanda, per creare un servizio tramite API servono delle Api-Keys, chi le fornisce e a chi? Si possono richiedere o reperire?

"questo giustificherebbe la presenza di servizi non conformi ma di fatto pubblicati. "

spero vivamente non sia così o, che chi può farlo, sia un soggetto affidabile altrimenti verrebbe meno il discorso del controllo back-office.

Fino al 30/09/2023 è stato così…dopo che siamo stati abilitati alle API services i servizi potevano essere pubblicati su app IO in autonomia. Da ottobre l’API services si è evoluta in API manage e il processo di pubblicazione di un servizio passa attravero il processo di revisione di PagoPA Bozza->Revisione->Approvazione|Rifiuto.
Con questo processo di pubblicazione dei servizi attraverso il backoffice del developer portal (utilizzato da un
delegato tecnico) diventa impossibile monitorare il processo di revisione dei servizi già a partire da pochi enti. Per ovviare a questo problema abbiamo implementato un nosto Backoffice che utilizza le API Manage per la gestione del processo revisione\pubblicazione dei servizi su app IO. Al momento stiamo testando l’applicazione su dei servizi reali e tutto sembrerebbe funzionare correttamente (solo qualche problema di gioventu’ che staimo risolvendo con l’onboarding di pagopa).

Buongiorno,
in riferimento ai sevizi duplicati e frazionati ho una situazione complicata.
Alcuni enti di nostra gestione hanno ricevuto segnalazione di servizio duplicato o frazionato. La problematica sta nel fatto che, alcuni servizi sono stati candidati nel fondo innovazione e ho il timore che la modifica di un servizio, per adeguarlo al catalogo, infici sulla candidatura del fondo innovazione. Qualcuno si è trovato nella mia stessa condizione? Purtroppo ho cercato su doc.pagopa.it e sulle faq ma non ho trovato risposte esaustive.

Buongiorno.
Sul tema ho un dubbio: un Comune cliente ci ha delegati all’onboarding sul backoffice di AppIO. I servizi sono stati validati mesi fa sul portale di developers.io, che ora è stato sostituito con la nuova Area riservata in cui è possibile importare dal vecchio portale i servizi. Questi servizi, però, non rispettano la nuova tassonomia e tuttavia risultano ancora validati; bisognerà andare a correggere ad un certo punto?

Se li hai candidati e non hai richiesto la seconda tranche di contributo del fondo innovazione, prosegui senza problemi e cambiali come ti viene chiesto.
Se hai ottenuto il contributo proprio per quelli, non sono candidabili al PNRR, perché si ricade nell’ipotesi di doppio finanziamento (e allora a maggior ragione vanno sostituiti i servizi incandidabili con altri nuovi ancora da realizzare).

1 Mi Piace