Specifiche Tecniche dei Processi di richiesta delle prestazioni tecniche - Consultazione di Acquirente Unico del 23 dicembre 2022

Elettricità Futura ha trasmesso all’Acquirente Unico le proprie osservazioni in relazione alle Specifiche Tecniche dei Processi di richiesta delle prestazioni tecniche in attuazione della Deliberazione 638/2022/R/eel.

In linea generale, Elettricità Futura concorda in larga parte con la struttura dei processi progettati da AU in quanto ripropongono le prassi che a oggi si concretizzano negli scambi bilaterali tra Controparti commerciali (CC) e imprese della distribuzione (DSO).

Il tema più rilevante che viene rilevato è la necessità di una maggiore semplificazione del set informativo dei flussi proposti, eliminando dai tracciati i campi dati ridondanti e/o che non vengono movimentati dai processi attualmente utilizzati (ad esempio indirizzo di fornitura, fatturazione, morosità). Questi dati, infatti, non solo risulterebbero poco utili per finalizzare le prestazioni tecniche, ma anche, nel caso in cui si decidesse di mantenerli, dovrebbero essere programmati e gestiti nei sistemi informatici, con oneri e complessità aggiuntive per gli operatori.

Tra le altre considerazioni proposte, inerenti i processi di sospensione, riattivazione e tracking:

• il processo di semplificazione dei flussi dovrebbe essere indirizzato anche al servizio di tracking;
• far seguire la pratica di sospensione da un processo di riattivazione piuttosto che da un flusso APN;
• all’avvenuta richiesta di switching, il DSO proceda direttamente alla riattivazione, procedendo poi ad aggiornare il SII;
• confermare l’attuale impostazione del SII che prevede sempre di annullare le pratiche in corso;
• necessità di attivare in contemporanea tutti e 3 i processi (sospensione, riattivazione e tracking), con richiesta di posticipare al 1° febbraio 2024 il go-live per tutti e 3 i processi.

Leggi il testo integrale delle osservazioni

Osservazioni generali

Ringraziamo Acquirente Unico per l’utile momento di confronto grazie al webinar del 19 gennaio. In linea generale, concordiamo in larga parte con la struttura dei processi progettati da AU in quanto, in un certo senso, ripropongono le prassi che a oggi si concretizzano negli scambi bilaterali tra Controparti commerciali (CC) e imprese della distribuzione (DSO).

Il tema sicuramente più rilevante su cui ci soffermiamo qui in premessa, e che infatti è stato oggetto di molteplici commenti in occasione del webinar, è la necessità di una maggiore semplificazione del set informativo dei flussi proposti. Riteniamo infatti importante eliminare dai tracciati proposti nel DCO i campi dati ridondanti e/o che non vengono movimentati dai processi utilizzati a oggi, ad esempio i campi sull’indirizzo di fornitura e fatturazione. Questi dati, infatti, non solo risulterebbero poco utili per finalizzare le prestazioni tecniche, ma anche, nel caso in cui si decidesse di mantenerli, dovrebbero essere programmati e gestiti nei sistemi informatici, con oneri e complessità aggiuntive per gli operatori.

Altri dati omissibili dai tracciati sono quelli relativi alla morosità, in particolare l’importo e la data in messa in mora. Come espresso da AU nel webinar, tali informazioni non sono oggetto di alcun controllo/monitoraggio o verifiche di congruità previste dalla regolazione e quindi essendo informazioni semplicemente “passanti”, si appesantirebbero in modo ingiustificato i flussi. Va inoltre sottolineato che tali dati, oltre a non essere necessari ai fini del processo in oggetto, non sarebbero nemmeno funzionali ad alcun tipo di monitoraggio o verifica di congruità in quanto presupporrebbero la conoscenza delle varie logiche (note solo al Trader) sottese alla gestione commerciale del cliente.

Un processo di semplificazione dei flussi dovrebbe essere indirizzato anche al servizio di tracking. Prevedere uno scambio di 4 diversi flussi tra SII e DSO, oltre a essere complesso da gestire per entrambe le parti, nella pratica ha un’utilità limitata. Sarebbe quindi necessario rimuovere i flussi TR1.0250 e TR1.0200 dato che il SII potrebbe già associare all’unica pratica il corretto step oggetto della fase di tracking tramite il campo previsto “CP_GESTORE_PT”.

Sempre restando in tema di semplificazione dei tracciati e di minimizzazione degli impatti per gli operatori, anche nel processo di revoca della sospensione, nell’ottica sia di andare in continuità con le prassi utilizzate oggi riteniamo preferibile che la pratica di sospensione sia seguita da un processo di riattivazione piuttosto che da un flusso APN come proposto in consultazione. Ciò in considerazione anche del fatto che il flusso APN, non gestendo un flusso di esito, non garantirebbe al SII la certezza dell’avvenuta esecuzione del processo né darebbe modo al DSO di riscontrare tempestivamente la suddetta attività.

Un’ulteriore considerazione riguarda la riattivazione a seguito di processi commerciali, quali voltura, switching o voltura con switching. Considerato che, ai sensi dell’articolo 6 del TIMOE, per queste pratiche la responsabilità per la riattivazione ricade sul DSO, anche in questo caso è preferibile andare in continuità con le prassi odierne, facendo sì che all’avvenuta richiesta di switching il DSO proceda direttamente alla riattivazione e procedendo poi ad aggiornare naturalmente il SII sia sullo stato di avanzamento della prestazione (mediante il servizio di tracking) sia sull’effettiva conclusione del processo di riattivazione.

Resta salvo il fatto che le operazioni intervenute ex ante in virtù della richiesta di sospensione in corso (es. riduzione di potenza) dovranno essere corrette (es. ripristino potenza originale). Riteniamo invece sia da confermare, l’attuale impostazione del SII che prevede sempre di annullare le pratiche in corso. Quindi nel caso residuale di “sospensione in corso” il distributore potrebbe ricevere dal SII anche la notifica di annullamento (APN) della sospensione, per averne specifica evidenza e interrompere tempestivamente ogni azione volta all’esecuzione della sospensione (evitando di avere dei punti erroneamente sospesi post acquisizione).

Ci soffermiamo infine sul tema delle tempistiche di entrata in vigore dei diversi processi. Diversamente da quanto viene previsto nelle Specifiche Tecniche e nella Delibera 638/2022/R/eel, evidenziamo come l’attivazione in contemporanea di tutti e 3 i processi (sospensione, riattivazione e tracking) è la soluzione ideale. Partire con i processi di sospensione e riattivazione ma senza avere il tracking attivo sarebbe tutt’altro che efficace, in quanto renderebbe impossibile agli operatori di svolgere la rilevante attività di verifica dell’avanzamento delle prestazioni.

Per risolvere questa criticità, riteniamo necessario che posticipo al 1° febbraio 2024 il go-live per tutti e 3 i processi (chiediamo un posticipo a febbraio perché l’implementazione congiunta di 3 nuovi flussi, attività già di per sé complessa, dal 1° gennaio sarebbe di difficile gestione da parte degli operatori). Considerato che la pianificazione ed eventuale modifica delle tempistiche di implementazione dei processi è subordinata a scelte e decisioni prese in ambito regolatorio, contemporaneamente a questa risposta, in cui abbiamo comunque ritenuto utile evidenziare la problematica, trasmetteremo un’apposita richiesta di posticipo ad ARERA.

Osservazioni di dettaglio

Paragrafo 5.2 – Modello generale del Processo di Riattivazione – RT

Al presente paragrafo il documento evidenzia che “La qualificazione degli Utenti al canale in application to application consente di minimizzare i tempi di invio dei flussi; viceversa l’utilizzo del canale massivo implica dei tempi ulteriori di elaborazione e spacchettamento dei file. Pertanto, per questa modalità non si garantisce il rispetto degli SLA del SII”.

Seppure comprendiamo quanto scritto, evidenziamo l’importanza che nel caso un operatore non utilizzi il canale application to application (ad esempio in caso di scorretto o mancato funzionamento dello stesso) e, di conseguenza, debba trasmettere la richiesta di riattivazione in modalità manuale, è indispensabile che il SII garantisca il rispetto delle tempistiche degli SLA. considerata la delicatezza e criticità del processo oggetto di consultazione. Una soluzione alternativa potrebbe essere quella di prevedere un canale puntuale, da utilizzare per la trasmissione manuale di richieste puntuali di riattivazione: per queste richieste il rispetto degli SLA dovrebbe essere garantito.

Oltre alle tipologie di riattivazione previste nel documento (R01: riattivazione per pratica errata; R02: riattivazione per revoca; R03: riattivazione su istanza del Gestore del SII) segnaliamo che ci possono essere riattivazioni che vengono trasmesse dalla società di vendita senza che il cliente abbia proceduto al pagamento dell’insoluto, e senza che ci sia stato un errore nell’invio della sospensione, per questo motivo sarebbe auspicabile prevedere anche una tipologia di riattivazione generica.

Fra i dati obbligatori da inviare nel flusso di riattivazione compare la "CP Gestore della pratica di sospensione". A nostro avviso è meglio non prevedere tale campo come obbligatorio, in quanto può succedere nel caso di POD sospesi prima dello switching, per cui è prevista la riattivazione di tipologia R03, che a causa di un disallineamento sullo stato del punto, questo non venga riattivato a seguito dello switching. In questi casi il cliente contatta il venditore reclamando di avere il contatore sospeso per morosità, e il venditore deve avere la possibilità di inserire una riattivazione per rialimentare il POD il prima possibile. Se viene richiesto il CP della pratica di sospensione, questo non sarà possibile.

Paragrafo 5.4 – Prevalenze tra processi e aggiornamento RCU

Domanda: L’UDD/CC titolare del punto vogliono ricevere notifica di riattivazione a seguito di esecuzione di prestazione commerciale? E cioè: se si acquisisce tramite switching un punto precedentemente sospeso, alla decorrenza dello switching il punto viene riattivato, L’UDD/CC vuole la notifica di riattivazione?

Riteniamo utile la notifica di riattivazione per il fornitore entrante e tutte le relative fasi di tracking. Occorre però chiarire con quale modalità riceveremo tali informazioni (es. tramite il flusso RT1.0150 e TR2.0200?).

Segnaliamo di seguito un caso particolare che merita un intervento apposito, ossia la situazione in cui il DSO non può riattivare un POD il punto, perché si tratta di contatore non telegestito e il cliente non risulta reperibile. In questo caso, il trader sarebbe infatti impossibilitato ad inserire una richiesta di riattivazione perché non conosce il codice pratica della sospensione precedente. A nostro avviso andrebbe previsto un flusso di notifica negativo verso il trader, il quale dovrà poter inserire una richiesta di riattivazione di tipologia diversa rispetto alle 3 proposte.

Domanda: Quali altre prestazioni tecniche gestite dai Distributori possono andare in conflitto con la richiesta di prestazioni tecniche?

I processi di variazioni potenza / spostamenti contatore / verifiche gruppo di misura potrebbero andare in conflitto con la sospensione. Occorre ricordare che la prestazione oggetto della presente consultazione è una prestazione particolare che normalmente non può che prevalere su qualsiasi altra prestazione tecnica considerata la finalità cui è destinata tranne che per rare eccezioni (ad esempio nel caso di una disattivazione in corso o di una richiesta c.d. M01/M02).

Paragrafo 6.2.1 – RT1 - Comunicazione Richiesta Prestazione Tecnica

Chiediamo di chiarire quale tipologia di RT1 deve essere inviata quando la riattivazione non integra né una riattivazione per revoca né una riattivazione per errore.

Proponiamo di rimuovere il campo “DATA_PAGAMENTO” dato che non ha alcuna finalità funzionale e sottintende logiche commerciali del cliente (in particolare del credito) complesse da gestire.

Presenza “non obbligatoria” dei dati sull’indirizzo mail e numero di telefono del cliente

Riteniamo che i dati “TELEFONO” e “MAIL” siano entrambi molto importanti per gli operatori al fine di avere riferimenti precisi per contattare il cliente in caso di necessità. Tuttavia, chiediamo di cambiare l’obbligatorietà dei due campi con la dicitura “SI (se disponibile)”.

Tabella A.4 – Stati di avanzamento Tracking (Flussi TR1.0050, TR1.0200 e TR2.0200)

Ai fini della semplificazione dei flussi, proponiamo di rendere disponibili in tabella solo gli stati funzionali e coerenti con i servizi centralizzati, senza censire stati coerenti con servizi che verranno centralizzati in futuro, o quelli relativi all’appuntamento. Di contro, al fine di intercettare particolari casistiche che possono essere peculiari per la prestazione di riattivazione, riteniamo utile che si aggiunga uno stato relativo a difficoltà di accesso da parte del DSO per contatore non accessibile, che potrebbe essere ad es. "in attesa di contatto da parte del cliente”.

Per quanto riguarda le informazioni relative all'intervento da parte del DSO, riguardo alle causali TR_006 e TR_007 relative alla programmazione dell'intervento l'informazione andrebbe limitata alla sola informazione sulla data, senza indicare l'ulteriore dettaglio di fascia oraria e/o orario - in coerenza peraltro con quanto riportato a pag. 16 della bozza di Specifiche in questione - in quanto quest’ultimo appare superfluo in funzione della natura e delle tempistiche estremamente ristrette per l'esecuzione dell'intervento (in particolare nel caso della riattivazione).

Infine, per quanto riguarda il COD_CAUSALE TR_004 “in attesa superamento causa di forza maggiore”, riteniamo che lo stesso possa essere eliminato o, in alternativa, chiediamo che sia fornita una definizione precisa dello stesso.

Semplificazione dei tracciati

Inoltre, riguardo al tema citato nelle osservazioni generali relativo alla semplificazione dei tracciati, riportiamo di seguito alcune ulteriori segnalazioni specifiche:

• nel flusso di invio richiesta (PT2.0050) oltre ai dati della sezione "Dati prestazione/morosità" possono essere eliminati i dati relativi a "DatiTecnici/Fornitura" e "ClienteFinale/Esazione";
• nel flusso di ammissibilità (PT2.0100) nella sezione "identificativo/richiesta" il campo "CP_DISTRIBUTORE" non deve essere obbligatorio poiché il dato non viene fornito se la richiesta è inammissibile;
• nel flusso di esito finale della riattivazione (RT2.0150) sono presenti, probabilmente per un refuso, i campi "FATTIBILITÀ" e "COSTO" non pertinenti con la prestazione di riattivazione per cui possono essere rimossi;
• il flusso Ammissibilità Esito (RT2.0151) riporta nel tracciato “COD_CAUSALE” e “MOTIVAZIONE” per i quali manca il riferimento alle tabelle da considerare. Analoga situazione in corrispondenza delle tabelle in calce al documento, in cui non è presente il riferimento al flusso RT2.0151, per cui andrebbe chiarito ed eventualmente corretto quanto indicato nelle Specifiche;
• altri refusi sono presenti a:
  1. pagina 16 - paragrafo 5.3: dopo TR2 errore del flusso di ammissibilità indicato come TR2.0100 invece di RT2.0100;
  2. pagina 37 - 6.2.1.1: indicato PT1.0050 anziché RT1.0050 e PT1.0100 anziché RT1.0100.

Ricapitolando, il set informativo minimo dei tracciati potrebbe essere il seguente:

• SM1:
• Codice servizio (SM1)
• Codice flusso (0050)
• partita iva utente (piva CC)
• partita iva distributore
• Pratica utente (identificativo prestazione)
• POD
• Dato fiscale
• Partita IVA
• telefono/mail (NON OBBLIGATORIO)
• Note (NON OBBLIGATORIO)
• R01
• codice servizio (R01)
• Codice flusso (0050)
• Partita IVA utente (piva cc)
• Partita IVA distributore
• Pratica utente (identificativo prestazione)
• POD
• Codice fiscale
• Partita iva
• telefono/mail (NON OBBLIGATORIO)
• Note (NON OBBLIGATORIO)