Prassi - MINISTERO DELLO SVILUPPO ECONOMICO - Circolare 15 maggio 2019, n. 3720/C
Art. 3-bis, comma 1, d.l. 18 settembre 1995, n. 381, convertito in L. 15 novembre 1995, n. 480 - Registro informatico dei protesti (RIP). - Decreto 14 novembre 2018 - "Approvazione delle specifiche tecniche per la trasmissione da parte degli ufficiali levatori degli elenchi dei protesti e dei rifiuti di pagamento con modalità esclusivamente telematica". - Trasmissione della "Specifica di interfaccia applicativa" (Allegato A)
In attuazione delle disposizioni di cui all’art. 3-bis del d.l. 19 settembre 1995, n. 381 convertito in legge 15 novembre 1995, n. 480 che istituisce il Registro informatico dei protesti (RIP), è stato adottato il decreto 14 novembre 2018 con il quale sono approvate nuove specifiche tecniche per la creazione di programmi informatici finalizzati alla compilazione degli elenchi dei protesti e dei rifiuti di pagamento mediante sottoscrizione con firma digitale e per la relativa trasmissione, esclusivamente in via telematica, alle camere di commercio, industria, artigianato e agricoltura da parte di tutti i pubblici ufficiali abilitati alla levata dei protesti o constatazioni equivalenti (Notai, Uffici notifiche esecuzioni e protesti (UNEP), Segretari comunali e Banca d’Italia), al fine del loro inserimento nel Registro informatico dei protesti.
Ai sensi dell’art. 2, comma 5, del suddetto decreto, si trasmette la "Specifica di interfaccia applicativa", "Allegato A" della presente circolare, contenente le modalità di presentazione degli elenchi dei protesti e dei rifiuti di pagamento a disposizione delle applicazioni informatiche che automatizzano l'operazione d'invio della pratica protesti tramite lo standard Web Services.
Tale documento dettaglia le caratteristiche tecniche del servizio di presentazione telematica della pratica protesti secondo lo standard WSDL, di cui al comma 1, lettera b, del decreto e fornisce le informazioni necessarie alle applicazioni informatiche per gestire correttamente l’operazione di invio.
Le "Specifiche di interfaccia applicativa" contengono altresì i riferimenti agli ambienti di collaudo funzionali all’esecuzione delle prove tecniche con InfoCamere preliminari all’utilizzo del sistema di produzione.
Al fine di favorire completezza, organicità e trasparenza nelle procedure di alimentazione del Registro informatico dei protesti, si forniscono di seguito ulteriori indicazioni operative e chiarimenti in ordine alla corretta gestione della trasmissione degli elenchi di protesti e dei rifiuti di pagamento e della relativa istruttoria della pratica da parte dei competenti uffici delle camere di commercio.
1. Trasmissione della pratica protesti
Tutti i campi previsti dalle specifiche tecniche di cui all’Allegato A del decreto 14 novembre 2018, anche quando definiti come facoltativi, devono essere valorizzati nel caso sussista la relativa informazione.
2. Istruttoria della pratica da iscrivere nel Registro protesti
Al momento della richiesta di trasmissione della pratica protesti da parte dell’Ufficiale Levatore, il servizio del sistema informatico del Registro informatico dei protesti provvede ad effettuare sulla pratica sottoposta alla spedizione i controlli automatici previsti dall’art. 3 e descritti nelle specifiche tecniche, di cui all’Allegato A del decreto 14 novembre 2018.
Nel caso di superamento di tutti i controlli automatici, la pratica viene trasmessa alla camera di commercio competente per l’espletamento delle verifiche istruttorie.
Al fine di uniformare l’attività istruttoria, di seguito sono indicate le verifiche relative alla correttezza formale, della pratica protesti affidate agli operatori degli uffici delle camere di commercio dall’art. 4, comma 2 del decreto:
a) Titolarità del soggetto che presenta la pratica
Nel caso in cui il codice fiscale della firma apposta sulla pratica in esame non coincida con quello dell’Ufficiale Levatore indicato nella pratica, l’operatore della camera verifica che il codice fiscale della firma coincida con quello di un suo delegato (es. notaio coadiutore) dichiarato alla camera di commercio con precedente comunicazione trasmessa via pec dall’Ufficiale Levatore.
b) Anomalie nella numerazione del repertorio
L’operatore della camera di commercio verifica che l’elenco dei numeri di repertorio nella pratica non presenti ripetizioni o evidenti incoerenze di numerazione (come ad esempio un numero di repertorio 80 all’interno di una sequenza di codici chiaramente diversi quali 20030, 20031, 20032, 20033, ...).
c) Date dei protesti
La data di levata dei protesti non deve superare il 26 del mese a cui si riferisce l’elenco trasmesso.
Nel caso la pratica protesti necessiti di correzioni, in applicazione dell’art. 4 del decreto, l’ufficio della camera di commercio ne richiede la modifica tramite la casella PEC dichiarata dal mittente, che si può riferire ad una persona fisica o all’ufficio dell’Ufficiale levatore competente.
Alla richiesta di correzione della camera di commercio, dovrà seguire il reinvio di una nuova pratica corretta entro i due giorni lavorativi successivi alla ricezione della richiesta inviata dall’ufficio.
3. Procedure di emergenza e presentazione del supporto informatico
Nel caso di mancato funzionamento degli strumenti ovvero dei dispositivi informatici dell’Ufficio del Registro informatico dei protesti, necessari alla ricezione della pratica, per un periodo superiore alle tre ore consecutive durante l’ultimo giorno disponibile per l’invio delle pratiche pretesti (ossia durante il primo giorno del mese), avuto riguardo all’orario ed ai giorni di apertura al pubblico della Camera di commercio, l’Ufficiale levatore è autorizzato a presentare la pratica su supporto informatico all’Ufficio competente per territorio.
In tal caso, le Camere di Commercio pubblicano un apposito comunicato sul sito invioprotesti.infocamere.it per avvisare gli Ufficiali levatori dell’avvenuto disservizio.
A partire dal 21 maggio 2019, le camere di commercio rendono disponibile sul sito web relativo ai protesti, invioprotesti.infocamere.it, la "Specifica di interfaccia applicativa" di cui all’Allegato A" della presente circolare.
Ai sensi e per gli effetti dell’art. 32 della legge 18 giugno 2009, n. 69, la presente circolare è pubblicata anche sul sito del Ministero dello sviluppo economico.
Con le medesime modalità saranno diramate e pubblicate eventuali successive modifiche od integrazioni alle presenti indicazioni operative ed ai contenuti tecnici del predetto allegato A.
Allegato A
Specifiche di interfaccia applicativa per l’invio delle pratiche protesti come da DM 14 novembre 2018 art. 2 comma 5
1 Introduzione al documento
1.1 Scopo e campo di applicazione del documento
Il documento ha l'obiettivo di descrivere le specifiche di interfaccia applicativa del servizio telematico di presentazione degli elenchi dei protesti e dei rifiuti di pagamento.
1.2 Termini e definizioni
In questa sezione si riportano termini e definizioni particolari e specifici del documento.
|
Termine |
Descrizione |
|---|---|
| eXtensible Markup Language | È un linguaggio derivato dall’SGML; quest’ultimo è un metalinguaggio, ossia un linguaggio che permette di definire altri linguaggi. Mentre l’HTML è un’istanza dell’SGML (quindi un semplice linguaggio), XML è un metalinguaggio come SGML nato dall’esigenza di avere a disposizione qualcosa di più semplice di quest’ultimo per descrivere i documenti sul Web.
XML viene utilizzato per definire le strutture dati invece che per descrivere come queste ultime devono essere presentate. Tali strutture vengono definite utilizzando dei marcatori (detti tags). Consente di definire marcatori personalizzati dandogli il controllo completo della struttura di un documento. Si possono definire anche gli attributi dei singoli tags. XML quindi, largamente utilizzato in Internet rappresenta lo standard "de facto" di definizione dei documenti. |
| SOAP (Simple Object
Access Protocol) |
SOAP è un protocollo per lo scambio di informazioni in ambiente distribuito e decentralizzato. È basato su tecnologie XML è consiste di tre parti: una busta (envolope) che definisce il quadro di riferimento per descrivere cosa è presente in un messaggio e come processarlo, un’insieme di regole di codifica per esprimere le istanze di strutture dati definite a livello applicazione ed una convenzione per il trasferimento di un contenuto applicativo. Può essere usato potenzialmente in combinazione con diversi protocolli di trasporto se bene per il momento siano stati definiti binding standard solo con http (SOAP ver. 1.1). |
| Web Service | I Web Service caratterizzano un sistema software identificato da un URI (RFC 2396), le cui interfacce pubbliche, il protocollo ed il formato dati (binding) sono definite e descritte utilizzando il linguaggio XML.
La definizione di un Web Service può essere scoperta da altri sistemi software, che possono quindi interagire con esso secondo le modalità prescritte nella sua definizione, mediante messaggi XML convogliate utilizzando protocolli Internet. |
| WSDL | Web Services Description Language |
| XML | eXtensible Markup Language |
| XML schema | Consente di specificare la struttura ed i vincoli dei documenti XML, rendendo possibile la descrizione della grammatica dei documenti XML. La differenza tra i due, XML schema e DTD, è il livello di dettaglio possibile nella descrizione delle strutture. XML Schema Part 0: Primer - W3C Recommendation, 2 Maggio 2001
http://www.w3.org/TR/xmlschema-0/ |
2 Web Service protesti
Il servizio in oggetto afferisce al WSDL di cui si riporta l’URL:
- collaudo: https://servizireprwscl.infocamere.it:52443/sepr/service/Protesti?wsdl
- produzione: https://servizireprws.infocamere.it:52443/sepr/service/Protesti?wsdl
Test di integrazione in ambiente di collaudo
Per procedere con il collaudo del sistema al fine dell’utilizzo del servizio in ambiente di produzione, si possono contattare le opportune strutture InfoCamere inviando una mail all’indirizzo: protesti@infocamere.it.
2.1 Operazione inviaPraticaByUtenteTelemaco
Il servizio inviaPraticaByUtenteTelemaco permette di eseguire la trasmissione telematica di un elenco protesti a partire dal file XML contenente la pratica (come costruito nel rispetto delle specifiche ministeriali) e dalle credenziali dell’Ufficiale Levatore per l’accesso ai servizi Telemaco.
L’input del servizio è costituito dai seguenti parametri:
- userid: user dell’utente che invia la pratica (abilitata ai servizi di invio pratiche protesti di Telemaco)
- password: password dell’utente che compila la pratica
- fileDatiFirmato: file dati XML della pratica firmato (.p7m)
L’output del servizio è costituito da due proprietà: Esito e Data.
|
Proprietà Esito | |
|---|---|
| Campo | Descrizione |
| returnEsito | OK o KO |
| returnCode | valore numerico identificativo del tipo di errore |
| returnMessage | descrizione del messaggio di errore |
| Note | |
| L'esito è positivo se il valore di returnEsito è ‘OK’ e quello di returnCode è ‘0’.
Nel caso in cui l’operazione non vada a buon fine i parametri returnEsito, returnCode e returnMessage valgono rispettivamente ‘KO’, un valore numerico diverso da ‘0’ e una descrizione parlante dell’errore. La lista dei messaggi di errore è disponibile in appendice. | |
|
Proprietà Data | |
|---|---|
| Campo | Descrizione |
| codicePraticaInput | codice pratica fornito in fase di invio |
| useridUtenteFinale | userid dell’utente che ha inviato la partica |
| codicePraticaOutput | codice pratica generato dalla procedura di invio |
| idPraticaOutput | id pratica generato dalla procedura di invio |
| Note: | |
| La proprietà Data è presente solo in caso di esito OK | |
3. APPENDICE 1: Codici e relativi messaggi di Errore
Di seguito vengono elencati i messaggi di output dell’operazione inviaPraticaByUtenteTelemaco con relativo codice di errore.
3.1 Messaggi d’errore forniti dal front-end
1 = Attenzione! I file in allegato hanno un codice pratica errato
2 = Attenzione è necessario fornire sia username che password
3 = Attenzione è necessario fornire username e password di sistema e user Telemaco
4 = Attenzione è necessario fornire username, timestemp e frase segreta
5 = Attenzione username e/o password errati
6 = Attenzione utente non abilitato
7 = Attenzione utente senza abilitazione da Ufficiale Levatore
8 = Attenzione è necessario fornire username, password, codice fiscale e codice fiscale ufficiale levatore
9 = Attenzione codice fiscale errato
10 = Attenzione codice fiscale Ufficiale Levatore errato
12 = Attenzione! Numero file in allegato errato
13 = Attenzione! I file in allegato non sono quelli attesi
14 = Attenzione! I file in allegato non sono firmati
3.2 Messaggi d’errore forniti dal back-end
15 = Attenzione! I file non sono firmati
16 = Attenzione! Le firme nei file non sono valide
17 = Attenzione! I codici fiscali del file dati e distinta non sono corretti
18 = Attenzione! Si è verificato un errore tecnico nel controllo delle firme
19 = Attenzione! Codice fiscale del firmatario non concide con quello della distinta
20 = Attenzione! Codice fiscale provincia e tipo nel file non coerente con quelli dell'ufficiale levatore
21 = Attenzione! Provincia dell'ufficiale levatore non corrisponde alla provincia di levata
22 = Attenzione! Potrebbe esserci un'incoerenza fra le date di emissione, di scadenza (se presente) e di levata
23 = Attenzione! PEC non valida
24 = Attenzione! PEC errata
25 = Attenzione! Il dominio della PEC non è certificato
26 = Attenzione! Il dominio della PEC non è convenzionato
27 = Attenzione! Problemi con lo stato della casella PEC
28 = Attenzione! Il Codice fiscale non è corretto formalmente. Codice Fiscale:
29 = Attenzione! Partita iva non corretta formalmente. Partita IVA:
30 = Attenzione! Il Codice fiscale non è coerente con i dati anagrafici
31 = Attenzione! Il numero di protesti dichiarato non corrisponde a quello effettivo
32 = Attenzione! Tipo elenco non congruente con i protesti trovati
33 = Attenzione! Problemi nel recupero della denominazione dell'impresa
98 = Errore Generico nella verifica della PEC
99 = Errore Generico