OLO2OLO Panservice: migrazioni e codici

Ambito e prerequisiti

Il modulo gestisce codici di migrazione, operatori e COW, migrazioni inviate, richieste ricevute e relative comunicazioni OLO2OLO Panservice. Occorrono il modulo attivo, i permessi assegnati e un accesso API abilitato dal fornitore.

Configurare versione e token

Aprire Impostazioni → OLO2OLO → API. Inserire il dominio HTTPS fornito da Panservice e scegliere v2 — modulo completo. La versione v1 consente soltanto creazione e verifica dei codici.

Creare un token statico nella sezione Profilo del portale OLO2OLO. I token ottenuti tramite login API scadono dopo 24 ore. Il token salvato non viene mostrato: lasciare il campo vuoto per conservarlo sullo stesso dominio; se cambia il dominio, inserire il relativo token.

Salvando v2 viene verificata l’autenticazione prima di accettare le nuove impostazioni. Con v1 il profilo non è verificabile.

Capire gli errori del token

Premere Verifica collegamento salvato per controllare il token delle impostazioni già salvate. La verifica è disponibile con v2 e conferma soltanto la validità al momento del controllo.

Un errore di autenticazione indica un token scaduto, revocato o non valido: Panservice non distingue sempre queste cause. Un errore di autorizzazione indica invece che il token non è abilitato alla funzione. Aggiornare il token oppure far verificare le abilitazioni al fornitore. Una funzione non trovata richiede di controllare dominio e versione; un errore di rete non dimostra la scadenza del token.

Operatori e COW

Con v2, consultare Operatori e filtrare denominazione corrente, denominazione originale o COW nativo. Il dettaglio raccoglie i riferimenti dell’operatore. La pagina COW permette di cercare per operatore, COW nativo e codice utilizzabile.

Creare e verificare un codice

Nella scheda del servizio aprire Gestione codice di migrazione → Crea codice migrazione, scegliere il COS e inserire la risorsa COR, da 6 a 12 caratteri alfanumerici. Confermare la creazione: il codice ottenuto viene associato al servizio. Per usare questa funzione deve essere abilitata la gestione OLO2OLO sul servizio.

Nel controllo codici inserire il codice completo di 9–19 caratteri. Leggere separatamente COW, COR, COS e checksum. La validità del codice non prova la titolarità o la migrabilità della linea: confrontare i dati con la documentazione del cliente.

Creare una migrazione

Con v2 aprire Migrazioni, inserire il codice completo e un riferimento ordine univoco di massimo 64 caratteri. Nome e cognome sono facoltativi, fino a 40 caratteri; le note fino a 255. Sono ammessi al massimo 10 numeri di directory, ciascuno di 6–12 cifre, separati da virgola, punto e virgola o a capo.

Il codice viene verificato prima dell’invio. La creazione conferma la ricezione della richiesta da parte di OLO2OLO e mostra l’identificativo della pratica; non ne conferma il completamento. Cercare il riferimento prima di ripetere un invio. Se l’esito è incerto o il salvataggio non riesce dopo l’accettazione, controllare il portale e contattare l’assistenza.

Leggere le comunicazioni

Nelle comunicazioni delle migrazioni inviate premere Aggiorna per tutte le pratiche oppure indicare il riferimento presente nell’elenco locale. Nelle richieste ricevute compaiono le pratiche per cui l’ISP è operatore cedente.

Le comunicazioni sono distinte per tipo, compresi controlli formali e gestionali; quelle già acquisite vengono riallineate. La data della comunicazione non indica da sola un avanzamento. La dicitura Comunicazione acquisita non significa migrazione completata. Consultare fase, risorsa e causale di rifiuto.

Le richieste ricevute sono aggiornate anche periodicamente per gli ISP abilitati; le comunicazioni delle migrazioni inviate si aggiornano dalla relativa pagina.

Inviare un rifiuto gestionale

Nelle richieste ricevute scegliere Risposta gestionale e una causale prevista. L’invio è disponibile solo se OLO2OLO consente ancora la risposta nello stato attuale della pratica.

Il comando Invia rifiuto comunica un esito negativo all’operatore: verificare ordine e causale prima di confermare. Le note libere non sono previste per questa risposta. Dopo l’invio aggiornare le comunicazioni per leggerne l’esito; non ripetere un invio di esito incerto.

Permessi e buone pratiche

Il permesso di lettura consente la consultazione e la verifica del collegamento. Creazione, aggiornamento delle comunicazioni e risposte gestionali richiedono il permesso di modifica. Ogni ISP consulta le proprie pratiche.

• Usare v2 per il modulo completo e un token statico dedicato.
• Verificare il collegamento quando compare un errore di autenticazione.
• Conservare un riferimento ordine univoco.
• Verificare linea, cliente e autorizzazione alla migrazione.
• Controllare il portale prima di ripetere un invio incerto.
• Non condividere token o dati personali nei messaggi di assistenza.