OLO2OLO Panservice: migrazioni e codici

Ambito

OLO2OLO è il modulo Panservice dedicato a operatori, COW, codici di migrazione, migrazioni inviate/ricevute e relative notifiche. FiberCop è un modulo separato e non condivide impostazioni o credenziali.

Configurazione API

Aprire Impostazioni → OLO2OLO → API e inserire la Base URL HTTPS e il token rilasciato da Panservice. La Base URL viene normalizzata senza slash finale; non aggiungere a mano percorsi di singoli endpoint.

Al salvataggio ISP Billing chiama il profilo autenticato: se token, ambiente o URL non sono validi, l’intera operazione viene annullata e i nuovi valori non vengono considerati configurati. Un accesso al portale Panservice non implica automaticamente accesso API.

Usare un token dedicato e revocabile, non copiarlo in screenshot, ticket o documenti. Dopo il salvataggio aprire Operatori: è la prima lettura utile per verificare anche autorizzazioni e forma della risposta, non soltanto la raggiungibilità.

Operatori e COW

Operatori interroga il catalogo remoto e permette di filtrare denominazione corrente, denominazione originale e COW nativo. Il dettaglio laterale raccoglie identificativo operatore, COW associati, endpoint, contatti, indirizzi IP e certificati: usare il dato corrente del provider quando occorre identificare mittente, destinatario o canale della migrazione.

COW è un elenco paginato remoto filtrabile per ID operatore, COW nativo e COW utilizzabile. Un operatore può avere più codici; non dedurre il codice dalla sola ragione sociale e non sostituire COW, COR o COS fra loro.

Verifica codice di migrazione

Inserire il codice completo nel form di controllo. La risposta va letta distinguendo formato, operatore e stato; una struttura sintatticamente valida non dimostra che la linea sia migrabile o che l’intestatario sia corretto.

Non correggere automaticamente un codice fornito dal cliente: confrontarlo con fattura o documento dell’operatore cedente.

Creare una migrazione

La migrazione può essere compilata con il codice completo oppure con le tre componenti COW, COR e COS. Se viene fornito il codice completo, ISP Billing rimuove gli spazi, lo converte in maiuscolo e, quando le componenti non sono già presenti, ricava COW dai primi tre caratteri, COS dall’ultimo e COR dalla parte centrale. Il controllo minimo locale non sostituisce Verifica codice.

Indicare il Codice Ordine Fornitura esterno; se manca, il sistema ne genera uno temporale. Cognome, nome e note sono facoltativi secondo la pratica. I Directory Number possono essere inseriti separati da virgola, punto e virgola o a capo e vengono inviati come elenco.

Invia file subito chiede a OLO2OLO di trasmettere immediatamente; disattivandolo, l’invio segue la pianificazione del server OLO2OLO. Prima di creare, cercare codice e ordine esterno nell’elenco per evitare duplicati. La risposta restituisce il codice ordine del provider, che ISP Billing salva insieme alla fotografia dei dati inviati.

Migrazioni create e stato reale

L’elenco locale mostra codice migrazione, ordine esterno, nominativo, stato di creazione e data. La creazione conferma che l’API ha accettato la richiesta e ha restituito un order code; non prova che il processo formale e gestionale sia concluso.

Non esiste nel modulo uno “stato del file inviato” da forzare o aggiornare manualmente. L’avanzamento reale arriva dalle comunicazioni OLO2OLO descritte nelle pagine Notifiche. Non creare una seconda migrazione per ottenere un nuovo stato.

Notifiche delle migrazioni inviate

Notifiche Richieste Migrazioni può aggiornare tutte le pratiche locali o il solo Codice Ordine indicato. Per ciascun ordine interroga la comunicazione inviata e memorizza una sola riga per coppia ordine/tipo comunicazione, evitando duplicati.

La tabella distingue, tra gli altri dati, tipo comunicazione (verifica formale o gestionale), destinatario, OLO donating, risorsa, stato richiesta, eventuale codice e motivo di rifiuto, data elaborazione, sessione, numeri directory e finestra di wait time. Leggere insieme stato, fase e causale: il solo colore della riga non basta a decidere l’esito operativo.

Migrazioni ricevute e gestione errore

Le notifiche ricevute riguardano pratiche nelle quali l’ISP è coinvolto come operatore cedente o destinatario. Aggiorna recupera dal provider l’elenco degli order code, ne legge il dettaglio e deduplica per ordine e tipo comunicazione. Sono conservati risorsa, servizio, sessione, directory number, cliente, date e gli eventuali errori formali e gestionali di fase 2.

Quando la procedura richiede una risposta gestionale, il comando dedicato invia a OLO2OLO Codice Errore e note aggiuntive per l’ordine selezionato e registra localmente la comunicazione. Scegliere esclusivamente una causale prevista dal processo e verificare ordine, risorsa e fase prima dell’invio: non è una nota interna e produce una comunicazione esterna.

Sincronizzazione pianificata

Il cron protetto scorre gli ISP che hanno impostazioni OLO2OLO, recupera gli order code delle migrazioni ricevute e importa soltanto combinazioni ordine/tipo comunicazione non ancora presenti. Un errore su una pratica o su un ISP viene registrato e non interrompe il controllo degli altri.

Il cron aggiorna le notifiche ricevute; le notifiche delle migrazioni create si aggiornano dalla relativa pagina, tutte insieme o per order code. Questa distinzione va considerata quando si costruisce la procedura operativa e quando si verifica una pratica apparentemente ferma.

Permessi e sicurezza

I permessi di lettura e modifica OLO2OLO devono essere assegnati solo agli operatori che gestiscono migrazioni. Liste, codici e notifiche contengono dati tecnici e vanno filtrati per ISP. Non riutilizzare i vecchi permessi o namespace Panservice rimossi.

Checklist

• Usare il solo modulo OLO2OLO
• Configurare credenziali API dedicate
• Verificare operatori e COW aggiornati
• Controllare il codice senza alterarlo
• Cercare pratiche già aperte
• Seguire notifiche inviate e ricevute
• Verificare linea e cliente
• Non forzare gli stati locali
• Limitare permessi e dati esposti