MANUALE PER LA PARTECIPAZIONE ALLE PROCEDURE CONCORRENZIALI
Manuale Utente
2 SOMMARIO
Introduzione ... 3
I concetti fondamentali ... 3
Utenti, operatori e profili ... 3
Il ciclo di vita della sessione ... 3
La garanzia finanziaria ... 3
Altre regole di accettazione delle offerte ... 4
L’esitO di un’offerta ... 4
Le transazioni della piattaforma ... 5
Il portale web ... 5
La home page... 5
Refresh, EXPORT in EXCEL e filtri ... 6
Lista COFER ... 7
Gestione deposito ... 7
Lista messaggi ... 8
Invio offerte ... 11
Invio di un’offerta ... 12
Modifica di un’offerta ... 14
Revoca di un’offerta ... 15
Invio multiplo di offerte ... 16
Revoca, modifica e invio contemporanei ... 18
Errori di validazione ... 19
Sforamento della garanzia finanziaria ... 19
Lista offerte ... 20
Sessioni ... 22
I file di esito della piattaforma ... 23
Market Result ... 23
Bid Notification ... 23
3 INTRODUZIONE
Questo manuale è rivolto all’utente della piattaforma Asta CO‐FER. In questo documento verranno esaminate in dettaglio tutte le funzionalità di competenza dell’utente. Verranno introdotti i concetti fondamentali quali il ciclo di vita della sessione d’asta, la garanzia finanziaria, le regole di accettazione delle offerte e le nozioni di utente, operatore e profilo.
I CONCETTI FONDAMENTALI
In questo capitolo vengono introdotti i principali concetti propedeutici alla piattaforma.
UTENTI, OPERATORI E PROFILI
Un operatore della piattaforma è un soggetto abilitato ad operare in una data sessione d’ asta. Esso può disporre di uno o più profili (Produttore, Trader, Impresa di vendita). Tali profili sono associati ad un unico operatore (condividono quindi la stessa ragione sociale e partita IVA, ma hanno diversi codici conto proprietà). Come vedremo, i vari vincoli di accettazione delle offerte (garanzia finanziaria, limite sul numero di offerte, limite sulla quantità) sono specifici di un operatore e quindi condivisi dai vari profili di quell’operatore.
Un utente è il soggetto che opera sulla piattaforma per conto di un profilo. Vi è quindi un’associazione 1 a 1 fra profilo ed utente. Un operatore con tre profili, avrà quindi altrettanti accessi che gli consentono di operare sulla Piattaforma.
IL CICLO DI VITA DELLA SESSIONE
Una sessione d’asta attraversa diversi stati, durante i quali un operatore può compiere determinate azioni.
Si definisce come data di flusso (o giorno di flusso) il giorno D in cui si chiude l’asta, viene eseguito l’algoritmo di abbinamento delle offerte e vengono confermati gli esiti.
Qui di seguito sono riportati gli stati, con relative tempistiche:
• NEW (Prima di D‐5 lavorativo): in questo stato l’operatore abilitato può dichiarare o modificare il proprio deposito di garanzia (si vedano più avanti i dettagli sull’operazione).
• PRED (dalle ore 10:00 di D‐3 lavorativo): in questo stato l’operatore non può più dichiarare o modificare il proprio deposito. L’amministratore della piattaforma esaminerà i depositi degli operatori, valutandone la coerenza con i bonifici bancari.
• OPEN (dalle ore 10:00 di D‐2 lavorativo): in questa fase l’operatore abilitato potrà inviare offerte, secondo le regole descritte più avanti.
• TERM (alle ore 10:00 di D): la sessione è terminata: l’operatore non può più sottomettere offerte.
• CLOS (entro le ore 17:00 di D): la sessione è definitivamente chiusa e i risultati dell’asta sono pubblicati sulla Piattaforma.
LA GARANZIA FINANZIARIA
L’operatore abilitato ad operare sulla piattaforma deve presentare una garanzia finanziaria sottoforma di un singolo deposito in contante infruttifero condiviso da tutti i profili di quell’operatore. L’operatore, mediante uno dei suoi profili deve dichiarare un deposito (cioè il suo ammontare) quando la sessione si trova in stato NEW. Come vedremo a pag. 7 un profilo dell’operatore sottomette un deposito e finché la sessione si trova in stato NEW, lo stesso profilo o un altro profilo dell’operatore possono modificare l’ammontare del deposito.
Manuale Utente
4
A questo punto il deposito si trova in attesa di conferma da parte dell’amministratore del portale. Durante la fase PRED della sessione l’amministratore verificherà l’esattezza del deposito, accettandolo, modificandolo o rifiutandolo.
All’apertura della sessione (stato OPEN), l’operatore (tramite i suoi profili) potrà sottomettere offerte sulla piattaforma. In sede di esecuzione dell’asta verrà eseguita la verifica di copertura della garanzia. Le offerte verranno ordinate per prezzo decrescente (e a parità di prezzo per data di sottomissione). A partire da quella con prezzo maggiore passeranno la fase di verifica tutte le offerte fino a copertura totale della garanzia. L’eventuale offerta che causa il superamento della garanzia denoterà la quantità tagliata in maniera opportuna. Le offerte totalmente fuori dalla copertura verranno rifiutate.
Ai fini del calcolo della garanzia, per ogni offerta si calcola il suo controvalore nella forma seguente:
a)
Dove p è il prezzo sottomesso, q la quantità sottomessa, iva è l’iva a cui è soggetto l’operatore, corr è il corrispettivo per la registrazione delle transazioni sulla piattaforma PB‐COFER.
ALTRE REGOLE DI ACCETTAZIONE DELLE OFFERTE
Oltre alla garanzia finanziaria le offerte sottomesse (o in sottomissione) sono soggette ad altri vincoli. Al momento dell’invio di un’offerta vengono approntate le seguenti restrizioni:
• Numero massimo di offerte: un operatore (quindi cumulativamente tutti i suoi profili), non può sottomettere più di cinque offerte per ogni tipologia di CO‐FER.
• Quantità massima: un operatore non può sottomettere un’offerta la cui quantità sia superiore al 50% della quantità messa all’asta dal GSE per quella data tipologia di CO‐FER (si noti che anche la somma della quantità complessivamente sottomessa per una data tipologia di CO‐FER è soggetta a tale vincolo, ma il controllo viene fatto pre esecuzione del mercato).
• Prezzo minimo: ogni offerta deve essere presentata con un prezzo maggiore o uguale al prezzo minimo pubblicato dal GSE.
• Quantità multiplo intero di mille: ogni offerta deve essere presentata con una quantità minima pari a 1000 MWh e comunque pari ad un multiplo intero di mille.
• Abilitazione del profilo: il profilo deve essere correntemente abilitato ad operare sulla piattaforma.
Una volta terminata la sessione (fase TERM), prima dell’esecuzione del mercato, vengono avviati altri controlli:
• Abilitazione del profilo: ancora una volta viene controllata l’abilitazione del profilo ad operatore sulla piattaforma.
• Quantità massima: in questa fase il controllo sulla quantità massima (pari al 50% della quantità offerta dal GSE) viene esteso alla quantità complessiva offerta per ogni tipologia di CO‐FER (includendo tutti i profili).
• Controllo di garanzia finanziaria: la questione è già stata introdotta.
L’ESITO DI UN’OFFERTA
Un’offerta passa attraverso diversi stati che evolvono con l’evoluzione della sessione d’asta. Quando la sessione è aperta (OPEN) la sessione può assumere i seguenti stati:
• Sottomessa: quando è stata inviata e presa in carico dal sistema (anche a seguito di una modifica dell’offerta stessa).
• Revocata: quando è stata cancellata dall’utente.
5 Al termine della sessione (CLOS), l’offerta può essere marcata così:
• Abbinata: se è stata accolta totalmente o parzialmente dall’algoritmo di abbinamento.
• Scartata: se non ha prodotto abbinamenti per merito economico. Questo accade quando l’offerta è scartata poiché la quantità offerta dal GSE è stata completamente abbinata con offerte più meritorie in termini economici o a parità di prezzo in termini temporali.
• Non valida: un’offerta può essere non valida a causa dell’esaurimento della garanzia, superamento del 50%
della quantità offerta dal GSE, profilo operatore non più abilitato.
LE TRANSAZIONI DELLA PIATTAFORMA
Ogni azione avviata dall’utente sulla piattaforma costituisce una transazione eseguita atomicamente dal sistema.
L’utente sottomette azioni interagendo attraverso delle pagine web. Ognuna di queste azioni genera automaticamente un file xml contenente i dati di input dell’azione. Una transazione è per esempio l’invio di un’offerta, oppure la dichiarazione di un deposito. Questi file xml vengono memorizzati permanentemente sul sistema. Ogni transazione genera un cosiddetto functional acknowledgement (FA) contenente l’esito della transazione (esito positivo oppure esito negativo con relativa motivazione). Anche lo FA è un file xml. L’utente può visualizzare in ogni momento i file xml di input e gli FA tramite la pagina lista messaggi, che analizzeremo in seguito, così come gli FA.
IL PORTALE WEB
Introdotti i vari concetti alla base della piattaforma, passiamo ora ad analizzare il portale web e le pagine in esso contenute.
In prima istanza analizzeremo l’impostazione generale del portale, poi passeremo a visionare le pagine.
LA HOME PAGE
In Figura 1 è visualizzata la homepage in cui sono riportati quattro numeri in rosso con lo scopo di individuare le aree da esaminare. Nell’area (1) sono riportate informazioni essenziali, quali: l’utente loggato (nell’esempio l’utente si chiama 0000001; in generale l’utente è identificato con il codice conto del profilo operatore a cui è legato l’utente. Di seguito è riportato il ruolo dell’utente (nel caso il ruolo è semplicemente denominato user, ed è disponibile solo tale ruolo). Vi è poi il pulsante di logout per abbandonare la piattaforma e ritornare al portale del GSE.
Sotto vi è la cosiddetta dashboard della sessione d’asta. Passando con il mouse su Sessione d’asta si apre un popup con i dati riassuntivi della sessione in corso. L’area (1) è visualizzata sempre, qualsiasi pagina sia caricata.
La sezione (2) riporta semplicemente gli estremi del profilo operatore con cui l’utente opera. Sono visualizzati la ragione sociale, il codice conto e il nome del profilo. Un utente tipico agisce per un singolo profilo operatore, quindi quel menù a tendina riporta una sola opzione.
Nella porzione (3) è riportata la pagina di benvenuto, in cui viene visualizzato un messaggio da parte degli amministratori, contenente avvisi, notifiche, informazioni utili, etc. Sotto, vengono riportati dati riassuntivi relativi all’ultima sessione. Nella figura la sessione risulta chiusa definitivamente e sono mostrati i risultati aggregati per ogni tipologia di CO‐FER.
Nel caso la sessione sia in stato OPEN, l’utente non visualizza più la homepage, ma la pagina di invio delle offerte, che vedremo in seguito.
Manuale Utente
6
Figura 1: la home page.
Nella sezione (4) sono riportate tutte le pagine a disposizione dell’utente successivamente descritte.
REFRESH, EXPORT IN EXCEL E FILTRI
Prima di passare ad esaminare le pagine, introduciamo alcune funzionalità comuni a diverse pagine di competenza dell’utente.
Come mostrato in Figura 2, una pagina contenente un report mostra una barra in cui sono riportati alcuni link.
(Mostra filtri…) permette all’operatore di espandere la sezione dei filtri (come mostrato in Figura 3) che permettono di circoscrivere il report ad un sottoinsieme di risultati. I filtri sono ovviamente specifici di ogni pagina web.
Figura 2: filtri, report excel e refresh.
Per ricaricare il report secondo i filtri impostati, occorre cliccare sul link refresh. Il link clear permette di cancellare i filtri, ritornando al contesto di partenza.
Figura 3: filtri.
Il link export serve per esportare il report in formato Microsoft Office Excel. Cliccando su export, un popup chiederà all’utente di salvare (o aprire) un file Excel contenente gli stessi risultati visualizzati (senza ovviamente la paginazione).
7 LISTA COFER
La pagina lista COFER mostrata in Figura 4 riporta semplicemente la lista di tipologie di CO‐FER abilitate per la seduta d’asta. In questa pagina è possibile solamente esportare la lista in Excel.
Figura 4: lista COFER.
GESTIONE DEPOSITO
Seguendo idealmente il ciclo di vita di una sessione d’asta, la prima azione che un utente deve compiere, è quella di dichiarare un deposito di garanzia, mediante la pagina gestione deposito.
Si ricorda che il deposito è comune a tutti i profili di un operatore ammesso alle procedure concorrenziali, pertanto i diversi profili vedranno gli stessi dati nella pagina in questione.
Figura 5: la sottomissione di un deposito.
Quando non esiste alcun deposito, la pagina si presenta come in Figura 5. Vi è semplicemente un link Crea nuovo deposito, cliccando sul quale si apre un popup come mostrato in Figura 6.
Manuale Utente
8
Figura 6: l'inserimento di un nuovo deposito.
Qui occorre inserire l’importo del deposito e includere eventuali note (opzionali). Premendo Insert, si procede con l’inserimento. Una volta inviato il deposito, ricaricando la pagina (o cliccando su refresh) quest’ultima mostrerà le informazioni nella forma riportata in Figura 7.
Figura 7: il deposito è stato creato.
Accanto all’ammontare, il link Modifica permette di editare l’importo iniziale. Si apre un popup simile a quella di figura Figura 6. Stato accettazione riporta lo stato del deposito. In questo momento è ancora in attesa della conferma dell’amministratore della piattaforma.
Si noti ancora una volta che la pagina è condivisa da tutti i profili di uno stesso operatore. Un altro profilo può quindi editare il deposito creato da un profilo diverso.
Come detto in precedenza, la creazione (o modifica) di un deposito è una transazione atomica gestita dal sistema.
L’utente interagisce con la pagina web sottomettendo automaticamente alla piattaforma un file xml contenente tutti i dati relativi alla transazione. Come risultato della transazione il sistema produce una Functional Acknowledgement (FA) in forma di file xml. Entrambi i file xml sono sempre visualizzabili nella pagina lista messaggi, oggetto del prossimo paragrafo.
LISTA MESSAGGI
La lista messaggi è una pagina molto importante dove l’utente può monitorare in ogni momento lo stato delle sue transazioni, attuali e remote nel tempo.
9
Nel paragrafo precedente l’utente ha sottomesso un deposito. Andiamo a vedere cosa vede a tal proposito nella lista messaggi (Figura 8).
Figura 8: la lista messaggi.
In questa pagina sono visibili tutte le transazioni inviate dall’operatore al sistema. Per semplicità al momento il report visualizza solo una transazione. Tutte le transazioni relative alla gestione di un deposito (creazione o modifica) avranno come oggetto del messaggio la stringa AccountActivity. Importante è lo stato del messaggio, che può assumere i seguenti valori:
• IN: la transazione è depositata nel sistema ma non è ancora stata eseguita.
• RUN: la transazione è in corso di esecuzione.
• OUT: la transazione è stata eseguita e l’esito (positivo o negativo) è disponibile nello FA.
• ERR: la transazione è fallita a causa di un errore non dipendente dalla transazione stessa (per esempio l’operatore non è più abilitato). La motivazione è scritta nello FA.
In transazione, altro campo molto importante, è riportato schematicamente l’esito della transazione: 1‐>1 indica che la transazione ha avuto successo (il deposito è stato inserito correttamente), 0‐>1 indica che la transazione non è andata a buon fine.
Si tenga conto che è possibile mandare contemporaneamente più transazioni (vedremo l’invio multiplo di offerte), per cui il campo transazione potrà assumere valori del tipo 8‐>10 ad indicare che su 10 transazioni, 8 sono andate a buon fine.
In questa pagina è possibile vedere anche i file xml che descrivono l’input e l’output della transazione. Essi sono visibili cliccando rispettivamente sulla cella Id messaggio e id messaggio out.
In Figura 9 si è cliccato su l’id messaggio e si è aperto il contenuto del messaggio xml di input. Senza scendere in inutili dettagli tecnici, è possibile comunque riconoscere i valori immessi nella maschera web di gestione del deposito, assieme ad altre informazioni utili per ricostruire il contesto della transazione, per esempio gli attributi MessageDate e MessageTime riportano la data e l’ora dell’invio, <Sender><OperatorMsgCode> riporta l’operatore che ha inviato la transazione, etc.
Allo stesso modo, in Figura 10 è riportato il messaggio xml contenente l’esito della transazione. In esso si riconosce il tag <FunctionalAcknowledgement> al cui interno, l’attributo Status riporta Accepted, cioè che la transazione è andata a buon fine. Ritorneremo ancora sugli FA, al momento in cui parleremo della sottomissione delle offerte.
Manuale Utente
10
Figura 9: il file di input.
Figura 10: un FA.
11
INVIO OFFERTE
La pagina dell’invio offerte è quella in cui il profilo operatore invia e gestisce (modifica o cancella) le offerte di competenza del profilo.
Nella Figura 11 è riportata la pagina quando ancora l’operatore (comprensivo dei tre profili) non ha ancora inviato offerte.
Figura 11: invio offerte.
Nella sezione (1) sono riportate le informazioni sulla garanzia finanziaria. Il deposito mostra l’ammontare iniziale della garanzia (ricordiamo, condiviso fra tutti i profili), mentre il controvalore totale riporta la garanzia impegnata dalle offerte correntemente sottomesse al sistema. Questo valore è calcolato sommando i vari controvalori ricavati con la formula a) riportata nel paragrafo La garanzia finanziaria. Vengono considerate le offerte sottomesse da tutti i profili.
La sezione (2) comprende i tre link seguenti:
‐ Ripulisci form: cancella tutti i campi di input della pagina.
‐ Mostra tutte le offerte: carica nei “tab” sottostanti le offerte già sottomesse (ma solo per il profilo associato all’utente).
‐ Invia tutte le offerte: tutte le offerte compilate nei tab sottostanti vengono inviate al sistema.
L’area (3) mostra diversi tab, uno per ogni tipologia di CO‐FER. Ogni tab reca al suo interno quanto identificato dalle aree (4) e (5). La sezione (4) riporta il prezzo minimo d’acquisto e la quantità oggetto dell’asta (ricordiamo che sono dati relativi alla singola tipologia di CO‐FER). La riga sottostante (Operatore) riporta il numero totale di offerte sottomesse (da tutti i profili dell’operatore) e la quantità totale sottomessa (da tutti i profili dell’operatore).
Manuale Utente
12
L’area (5) riporta al suo interno il vettore di offerte per ogni tipologia di CO‐FER. Sono anche disponibili i link ripulisci questo pannello, per cancellare il contenuto del vettore e il link mostra offerte, per caricare le offerte relative a quella tipologia.
Infine la sezione (6) permette di inserire delle note (opzionale).
L’ordine delle offerte è quello visualizzato dalla sequenza dei “tab”, se l’utente desidera dare priorità ad una particolare tipologia deve compilare il form del tab relativo ed inviarla per prima.
Passiamo adesso ad esaminare in dettaglio le azioni possibili sulla pagina.
INVIO DI UN’OFFERTA
L’operatore invia una singola offerta per la tipologia COFER Idroelettrico 2012 (Figura 12). Per far questo, immette un prezzo pari a 5 €/MWh e quantità 4000 MWh.
Figura 12: invio di un'offerta.
Quindi clicca su invia tutte le offerte e visualizza una preview che riassume le azioni che l’utente si appresta ad inviare (Figura 13).
Figura 13: preview dell'offerta da inviare.
Se l’utente si accorge di un errore, può cliccare su indietro, per tornare alla compilazione, altrimenti, clicca su invia tutte le offerte e finalmente l’offerta viene inviata giungendo alla schermata in cui si viene avvertiti dell’avvenuto invio (Figura 14)
13
Figura 14: conferma dell'invio.
Prima di proseguire, passiamo per un attimo sulla pagina lista messaggi, in cui visualizziamo (Figura 15) la lista dei messaggi da e per la piattaforma. Oltre al precedente AccountActivity, adesso è riportato un file con oggetto Offers, di cui si può vedere che l’esito è andato a buon fine (1‐>1).
Figura 15: messaggio Offers.
Diamo un’occhiata anche al file FA (Figura 16) per vedere come è segnalato in maniera formale l’esito della transazione. Si noti la presenza anche dell’attributo RefId contenente l’id univoco assegnato dalla piattaforma all’offerta (ci verrà utile quando valuteremo le Bid Notification (BN) e la lista offerte.
Figura 16: lo FA.
Ritorniamo alla pagina invio offerte, che mostra le informazioni aggiornate (Figura 17). Nella sezione (1) riporta il controvalore aggiornato inclusivo del corrispettivo di registrazione di ogni CO‐FER sulla PB‐COFER.
Manuale Utente
14
Si noti anche come nell’area (2) della fig. 17 viene riportata 1 offerta sottomessa complessivamente, e quantità totale pari a 4000 MWh.
Infine nell’area (3), ovvero il vettore d’offerta, è visualizzata l’offerta sottomessa dal profilo associato all’utente. E’
comparso però un menù a tendina che permette di:
‐ Modificare l’offerta (Modify): qualora si cambino il prezzo e/o la quantità e ripetendo la procedura invia tutte le offerte, si procederà con la modifica dell’offerta.
‐ Eliminare l’offerta: in quel caso l’offerta verrà cancellata e di conseguenza il controvalore totale diminuirà della quantità relativa.
Figura 17: pagina offerte con una sola offerta.
MODIFICA DI UN’OFFERTA
Alteriamone la quantità modificandola da 4000 MWh a 5000 MWh e premiamo invia tutte le offerte.
In Figura 18 è riportata la preview dell’azione di modifica. Notiamo, cerchiato in rosso, la segnalazione che l’offerta sta per essere modificata.
15
Figura 18: la preview di una modifica.
REVOCA DI UN’OFFERTA
Allo stesso modo si può procedere con la cancellazione dell’offerta, selezionando dal menù a tendina la voce delete (Figura 19).
Figura 19: cancellazione di un'offerta.
In tal caso avremo una diversa preview (Figura 20).
Figura 20: preview di una cancellazione.
Manuale Utente
16
INVIO MULTIPLO DI OFFERTE
E’ inoltre possibile inviare più offerte contemporaneamente, come mostrato in Figura 21. Si noti che per questa occasione abbiamo selezionato il tab COFER Solare 2012 e inserito tre offerte.
Figura 21: invio multiplo di offerte.
Nel caso di un’invio multiplo, la preview visualizzerà tutte le offerte in via di sottomissione.
Una volta inviate le offerte passiamo a visualizzare la pagina lista messaggi, per sincerarci dell’effettivo successo delle sottomissioni. Esaminiamo il file di output, ovvero lo FA (Figura 23)
Figura 22: preview di un invio multiplo di offerte.
17
Figura 23: FA di un invio multiplo di offerte.
Si considera una transazione l’invio di una singola offerta, pertanto a seguito dell’invio di tre offerte avremo altrettante transazioni, ognuna delle quali avrà un esito riportato nel file FA. Osserviamo i tre tag FunctionalAcknowledgement che riportano l’esito (positivo) delle tre transazioni. L’ordine è rigorosamente quello visto nella preview. E’ inoltre disponibile il RefId, ovvero l’id univoco assegnato dal sistema all’offerta.
Figura 24: un FA con transazioni accettate e non accettate.
Manuale Utente
18
Per completezza riportiamo anche un esempio di FA con alcune transazioni accettate e altre invece no. Come è possibile vedere in Figura 24, le transazioni non accettate riportano l’attributo Status=”Rejected” e sotto è riportata la ragione.
REVOCA, MODIFICA E INVIO CONTEMPORANEI
E’ inoltre possibile operare azioni differenti nello stesso momento. In Figura 25 sono mostrate tre azioni, rispettivamente: cancellazione, modifica (quantità da 20000 MWh a 21000 MWh) e inserimento di una nuova offerta.
Figura 25: cancellazione, modifica e invio.
La prima offerta, non è stata modificata, quindi ci aspettiamo che essa non compaia nella preview (Figura 26).
Figura 26: la preview delle tre azioni.
19
ERRORI DI VALIDAZIONE
Eventuali errori di validazione sono mostrati con una scritta rossa sotto all’offerta che ha causato l’errore (Figura 27).
Figura 27: errori di validazione
SFORAMENTO DELLA GARANZIA FINANZIARIA
Nel caso la garanzia finanziaria sia totalmente impegnata, al momento della sottomissione di un’offerta, un warning avverte l’operatore che non vi è più garanzia disponibile. L’utente può scegliere se continuare oppure tornare indietro (Figura 28).
Figura 28: warning superamento garanzia finanziaria.
Qualora la garanzia finanziaria sia effettivamente superata, il controvalore totale mostrato nella pagina di invio offerte viene evidenziato in rosso (Figura 29).
Manuale Utente
20
Figura 29: sforamento della garanzia finanziaria.
LISTA OFFERTE
La pagina lista offerte permette di visualizzare tutte le offerte di competenza del profilo operatore associato all’utente (Figura 30), quindi non solo quelle della sezione corrente.
Figura 30: la lista offerte.
Come si vede in figura, i filtri a disposizione permettono di:
• Selezionare un periodo di sottomissione (data inizio e data fine),
• una data di flusso (ricordiamo è il giorno D della sessione d’asta),
• lo stato dell’offerta (sottomessa, revocata, scartata, non valida, abbinata)
• il tipo di CO‐FER.
• L’id dell’offerta.
Le colonne visualizzate nel report, sono invece le seguenti:
21
• Tipologia di CO‐FER
• Il profilo operatore che ha sottomesso l’offerta
• La ragione sociale
• Il tipo di offerta
• La quantità sottomessa
• La quantità premiata, ovvero quella accettata dall’algoritmo
• La quantità residuale, ovvero rimanente una volta chiusa l’asta.
• La quantità rifiutata, ovvero la quantità tagliata per motivi legati alla garanzia finanziaria o superamento della soglia del 50% della quantità offerta dal GSE.
• Il prezzo sottomesso
• La data e l’ora di sottomissione
• Lo stato dell’offerta
• L’id univoco assegnato dal sistema all’offerta.
• L’utente che ha sottomesso l’offerta
• Eventuali note. In caso di taglio della quantità offerta, la piattaforma include nelle note un messaggio che evidenzia la ragione del taglio: “THRESHOLD EXCEEDING” per il superamento della soglia del 50%;
“WARRANTY LIMIT EXCEEDING” per il superamento della garanzia.
In Figura 31 sono riportate altre offerte, fra cui alcune in stato non valido. Passando con il mouse sullo stato è possibile visualizzare la ragione per cui un’offerta è marcata come non valida.
Figura 31: un report offerte con offerte non valide.
Manuale Utente
22 SESSIONI
Infine abbiamo la pagina con la lista delle sessioni delle aste. In essa compare la sessione corrente e quelle passate (Figura 32). Per ogni sessione conclusa, sono riportate informazioni essenziali suddivise per tipologia di CO‐FER:
quantità scambiata, quantità in vendita, quantità in acquisto, prezzo minimo di abbinamento e prezzo massimo di abbinamento.
Figura 32: la lista delle sessioni
Cliccando sul nome della tipologia di CO‐FER è possibile visualizzare un grafico con le curve di domanda ed offerta (Figura 33).
Figura 33: il grafico con le curve di domanda e offerta.
23 I FILE DI ESITO DELLA PIATTAFORMA
Al termine della sessione d’asta (CLOS), cioè alla chiusura definitiva, la piattaforma emette due file xml:
• Market results (MR): contiene gli esiti aggregati della sessione.
• Bid notification (BN): contiene gli esiti per ogni offerta inviata dal profilo operatore.
Andiamo ad esaminare i due file, che sono disponibili nella solita lista messaggi e sono individuabili facilmente poiché l’oggetto del messaggio è MR o BN ed entrambi mancano dell’id messaggio di input, essendo essenzialmente file di output non associati direttamente ad una transazione utente.
MARKET RESULT
Il file MR riporta al suo interno gli esiti aggregati già visibili nella pagina delle sessioni. In Figura 34 è riportato un esempio in cui è facile riconoscere i vari dati suddivisi per tipologia di CO‐FER.
Figura 34:il file MR.
BID NOTIFICATION
Riguardo la BN, in Figura 35 è riportato un esempio in cui un’offerta è stata premiata dall’algoritmo (Status awarded), ma è stata precendentemente tagliata per superamento della garanzia. Della quantità originale pari a 45000 MWh, è stata tagliata una quantità pari a 44000 MWh e quindi è stata abbinata una quantità pari a 1000 MWh.
Manuale Utente
24
Figura 35: il file BN.
La seconda offerta mostrata invece è stata resa non valida (Incongrous) poiché non vi era più garanzia finanziaria.
