PROROGARE AUTOMATICAMENTE LE ESENZIONI E01 E03 E04

Lucio Mignone Mer 21 Mar 2012 - 23:08

Poiché in Toscana sono state automaticamente rinnovate le esenzioni E01, E03 ed E04
questa rinnova automaticamente tutte e tre le esenzioni sino al 31/03/2013:

UPDATE DBA.cart_paz_ese SET dscdese = '2013-03-31'
WHERE dscdese = '2012-03-31' AND cod_ese = 'RE1' OR cod_ese = 'RE3' OR cod_ese = 'RE4';
commit;
select 'Comando eseguito con successo!' as Risultato;

Se
si lavora in gruppo il comandio precedente aggiorna i database di tutti
gli utenti, motivo per cui se si vuole agire esclusivamente sul proprio archivio
pazienti, senza aggiurnare gli archivi degli altri colleghi, occore utilizzare questa:

UPDATE DBA.cart_paz_ese SET dscdese = '2013-03-31'
WHERE dscdese = '2012-03-31' AND cod_ese = 'RE1' AND Userid= 'XXXXX' OR cod_ese = 'RE3' AND Userid= 'XXXXX' OR cod_ese = 'RE4' AND Userid= 'XXXXX';
commit;
select 'Comando eseguito con successo!' as Risultato;

Ovviamente inserire al posto di XXXXX il proprio codice di medicina di gruppo

Lucio Mignone Gio 22 Mar 2012 - 0:21

PICCOLA CORREZIONE,
con queste l'aggiornamento automatico della data di scadenza al 31/03/2013
avviene anche se si sono inserite le esenzioni in oggetto ma si era lasciata vuota la data di scadenza

UPDATE DBA.cart_paz_ese SET dscdese = '2013-03-31'
WHERE (dscdese = '2012-03-31' OR dscdese IS NULL) AND cod_ese = 'RE1' OR cod_ese = 'RE3' OR cod_ese = 'RE4';
commit;
select 'Comando eseguito con successo!' as Risultato;

Se si lavora in gruppo il comandio precedente aggiorna i database di tutti
gli utenti, motivo per cui se si vuole agire esclusivamente sul proprio archivio
pazienti, senza aggiurnare gli archivi degli altri colleghi, occore utilizzare questa:

UPDATE DBA.cart_paz_ese SET dscdese = '2013-03-31'
WHERE (dscdese = '2012-03-31' OR dscdese IS NULL) AND cod_ese = 'RE1' AND Userid= 'XXXXX' OR cod_ese = 'RE3' AND Userid= 'XXXXX' OR cod_ese = 'RE4' AND Userid= 'XXXXX';
commit;
select 'Comando eseguito con successo!' as Risultato;

Ovviamente inserire al posto di XXXXX il proprio codice di medicina di gruppo

Ho postato anche nella sezione statistiche ed estrazioni poichè mi sembrava approrpiato.

Lucio Mignone Gio 22 Mar 2012 - 10:44

Ho verificato che il comando di cui al precedente mio post funziona bene per cui i colleghi toscani possono utilizzarlo.
Se ci sono difficoltà scrivete.

Lucio Mignone Gio 29 Mar 2012 - 16:02

Qualche correttivo.
Questa è migliore, poiché cancella anche il messaggio di promemoria scadenza esenzioni che viene scritto in Paziente >flash e scadenzario > promemoria scadenze

update cart_paz_ese set dscdese= '2013-03-31', sigla_si=upper(sigla_si)
where cod_ese in ('RE1','RE3','RE4') AND dscdese = '2012-03-31' OR dscdese is null;
DELETE cart_scadenze
FROM cart_scadenze s join cart_paz_ese e on s.codice = e.codice and s.rowid = e.rowid and s.tabella = 'E'
where e.cod_ese in ('RE1','RE3','RE4');
commit;
select 'Fine Elaborazione Dati' as FINE;

***Attenzione*** nella delibera è scritto che le esenzioni sono rinnovate sotto responsabilità del paziente che dichiara di essere sempre nella stessa situazione che ha determinato il rilascio della prima esenzione a scadenza 31/03/12. Per cui rinnovandole tutte di nostra iniziativa ed in una sola volta non so se comporti una qualche nostra assunzione di responsabilità in quanto inseriamo nel programma un diritto all'esenzione per tutti questi pazienti, anche per quelli che potrebbero non averne più effettivamente diritto.

filippo Sab 31 Mar 2012 - 15:20

Lavoro in Toscana
Ho usato l'utima versione della estrazione ma mi sono accorto che c'è un errore:
mette la scadenza a tutte le esenzioni che non la hanno (ipertensione invalidita' varie etc etc ).
Qualcuno che la gia'ì usata puo' controllare?

**drtulino** Sab 31 Mar 2012 - 17:06

filippo ha scritto:Lavoro in Toscana
Ho usato l'utima versione della estrazione ma mi sono accorto che c'è un errore:
mette la scadenza a tutte le esenzioni che non la hanno (ipertensione invalidita' varie etc etc ).
Qualcuno che la gia'ì usata puo' controllare?

Sul sito di Millewin è stato pubblicato il nuovo file "regole" ed andando nell'apposita pagina sotto "Regione Toscana" è possibile scaricare l'applicazione per modificare tutte le date.

Lucio Mignone Sab 31 Mar 2012 - 20:05

filippo ha scritto:Lavoro in Toscana
Ho usato l'utima versione della estrazione ma mi sono accorto che c'è un errore:
mette la scadenza a tutte le esenzioni che non la hanno (ipertensione invalidita' varie etc etc ).
Qualcuno che la gia'ì usata puo' controllare?

Si c'è un errore. Grazie per averlo segnalato.
Nel copia ed incolla mi sono perso un pezzo...
Questa dovrebbe andare bene

update cart_paz_ese set dscdese= '2013-03-31', sigla_si=upper(sigla_si)
where cod_ese in ('RE1','RE3','RE4') AND dscdese = '2012-03-31' OR cod_ese in ('RE1','RE3','RE4') AND dscdese is null;
DELETE cart_scadenze
FROM cart_scadenze s join cart_paz_ese e on s.codice = e.codice and s.rowid = e.rowid and s.tabella = 'E'
where e.cod_ese in ('RE1','RE3','RE4');
commit;
select 'Fine Elaborazione Dati' as FINE;

La pubblico per esercizio e scopo didattico...
Come ha scritto Renato, infatti, sul sito c'è la pacth ufficiale.
Ecco il link
http://www.millewin.it/download/regioni/docs/Toscana/MilleProrogaEsenzioni.exe

**Admin** Sab 31 Mar 2012 - 20:38

Sempre a scopo didattico:

update cart_paz_ese set dscdese= '2013-03-31', sigla_si=upper(sigla_si)
where cod_ese in ('RE1','RE3','RE4') AND (dscdese = '2012-03-31' OR dscdese is null);
DELETE cart_scadenze
FROM cart_scadenze s join cart_paz_ese e on s.codice = e.codice and s.rowid = e.rowid and s.tabella = 'E'
where e.cod_ese in ('RE1','RE3','RE4');
commit;
select 'Fine Elaborazione Dati' as FINE;

Lucio Mignone Sab 31 Mar 2012 - 23:23

Admin ha scritto:Sempre a scopo didattico:

update cart_paz_ese set dscdese= '2013-03-31', sigla_si=upper(sigla_si)
where cod_ese in ('RE1','RE3','RE4') AND (dscdese = '2012-03-31' OR dscdese is null);
DELETE cart_scadenze
FROM cart_scadenze s join cart_paz_ese e on s.codice = e.codice and s.rowid = e.rowid and s.tabella = 'E'
where e.cod_ese in ('RE1','RE3','RE4');
commit;
select 'Fine Elaborazione Dati' as FINE;

L'importanza delle parentesi....
Oltre al funzionamento rendono meglio leggibile la query.
Grazie Giuseppe.

teo_savi Dom 15 Apr 2012 - 18:22

Admin ha scritto:Sempre a scopo didattico:

update cart_paz_ese set dscdese= '2013-03-31', sigla_si=upper(sigla_si)
where cod_ese in ('RE1','RE3','RE4') AND (dscdese = '2012-03-31' OR dscdese is null);
DELETE cart_scadenze
FROM cart_scadenze s join cart_paz_ese e on s.codice = e.codice and s.rowid = e.rowid and s.tabella = 'E'
where e.cod_ese in ('RE1','RE3','RE4');
commit;
select 'Fine Elaborazione Dati' as FINE;

in veneto le esenzioni 'RE1','RE2','RE3','RE4' (alias 7R2 7R3 7R4 7R5) sono state prorogate al 31/05/2012.
quindi ho aggiornato la query come segue

update cart_paz_ese
set dscdese= '2012-05-31', sigla_si=upper(sigla_si)
where cod_ese in ('RE1','RE2','RE3','RE4') AND (dscdese = '2012-03-31' OR dscdese is null);
DELETE cart_scadenze
FROM cart_scadenze s join cart_paz_ese e on s.codice = e.codice and s.rowid = e.rowid and s.tabella = 'E'
where e.cod_ese in ('RE1','RE2','RE3','RE4');
commit;
select 'Fine Elaborazione Dati' as FINE;

prima di lanciarla, mi resta un dubbio: cosa si cancella in cart_scadenze? tutte le scadenze 'RE1','RE2','RE3','RE4' o solo
quelle aggiornate dalla query, omettendo quindi quelle già aggiornate
manualmente al 31/05/12 o già confermate al 31/03/13? nel primo caso sarebbe corretto
modificare quindi

where e.cod_ese in ('RE1','RE2','RE3','RE4') AND (e.data_scad = '2012-03-31' OR data_scad is null)

o è sbagliato???

**Admin** Dom 15 Apr 2012 - 22:32

teo_savi ha scritto:

in veneto le esenzioni 'RE1','RE2','RE3','RE4' (alias 7R2 7R3 7R4 7R5) sono state prorogate al 31/05/2012.
quindi ho aggiornato la query come segue

update cart_paz_ese
set dscdese= '2012-05-31', sigla_si=upper(sigla_si)
where cod_ese in ('RE1','RE2','RE3','RE4') AND (dscdese = '2012-03-31' OR dscdese is null);
DELETE cart_scadenze
FROM cart_scadenze s join cart_paz_ese e on s.codice = e.codice and s.rowid = e.rowid and s.tabella = 'E'
where e.cod_ese in ('RE1','RE2','RE3','RE4');
commit;
select 'Fine Elaborazione Dati' as FINE;

prima di lanciarla, mi resta un dubbio: cosa si cancella in cart_scadenze? tutte le scadenze 'RE1','RE2','RE3','RE4' o solo
quelle aggiornate dalla query, omettendo quindi quelle già aggiornate
manualmente al 31/05/12 o già confermate al 31/03/13? nel primo caso sarebbe corretto
modificare quindi

where e.cod_ese in ('RE1','RE2','RE3','RE4') AND (e.data_scad = '2012-03-31' OR data_scad is null)

o è sbagliato???

Non ho capito quale è il codice interno per le esenzioni: RE1, RE2, ecc. o 7R2, 7R3, ecc., perché nel caso fossero i secondi, il comando va cambiato. Per quanto riguarda la seconda parte vengono cancellati gli avvisi di scadenza relativi solo alle variazioni effettuate.

teo_savi Lun 16 Apr 2012 - 0:54

Admin ha scritto:
teo_savi ha scritto:

in veneto le esenzioni 'RE1','RE2','RE3','RE4' (alias 7R2 7R3 7R4 7R5) sono state prorogate al 31/05/2012.
quindi ho aggiornato la query come segue

update cart_paz_ese
set dscdese= '2012-05-31', sigla_si=upper(sigla_si)
where cod_ese in ('RE1','RE2','RE3','RE4') AND (dscdese = '2012-03-31' OR dscdese is null);
DELETE cart_scadenze
FROM cart_scadenze s join cart_paz_ese e on s.codice = e.codice and s.rowid = e.rowid and s.tabella = 'E'
where e.cod_ese in ('RE1','RE2','RE3','RE4');
commit;
select 'Fine Elaborazione Dati' as FINE;

prima di lanciarla, mi resta un dubbio: cosa si cancella in cart_scadenze? tutte le scadenze 'RE1','RE2','RE3','RE4' o solo
quelle aggiornate dalla query, omettendo quindi quelle già aggiornate
manualmente al 31/05/12 o già confermate al 31/03/13? nel primo caso sarebbe corretto
modificare quindi

where e.cod_ese in ('RE1','RE2','RE3','RE4') AND (e.data_scad = '2012-03-31' OR data_scad is null)

o è sbagliato???

Non ho capito quale è il codice interno per le esenzioni: RE1, RE2, ecc. o 7R2, 7R3, ecc., perché nel caso fossero i secondi, il comando va cambiato. Per quanto riguarda la seconda parte vengono cancellati gli avvisi di scadenza relativi solo alle variazioni effettuate.

il codice interno MW è 'RE1','RE2','RE3','RE4', il codice stampato sulle ricette è 7R2 7R3 7R4 7R5

grazie per la risposta

Guido Gio 7 Giu 2012 - 18:24

Lucio Mignone ha scritto:

Se si lavora in gruppo il comandio precedente aggiorna i database di tutti
gli utenti, motivo per cui se si vuole agire esclusivamente sul proprio archivio
pazienti, senza aggiurnare gli archivi degli altri colleghi, occore utilizzare questa:

UPDATE DBA.cart_paz_ese SET dscdese = '2013-03-31'
WHERE (dscdese = '2012-03-31' OR dscdese IS NULL) AND cod_ese = 'RE1' AND Userid= 'XXXXX' OR cod_ese = 'RE3' AND Userid= 'XXXXX' OR cod_ese = 'RE4' AND Userid= 'XXXXX';
commit;
select 'Comando eseguito con successo!' as Risultato;

Ovviamente inserire al posto di XXXXX il proprio codice di medicina di gruppo

Ho postato anche nella sezione statistiche ed estrazioni poichè mi sembrava approrpiato.

Leggo solo ora questo post.
A mio parere c'e' una imprecisione.
Userid memorizza il codice dell'ultimo modificatore del record dell'esenzione, e puo' essere quindi anche il codice di un sostituto o di un altro medico del gruppo.
Per selezionare quindi i records cart_paz_ese dei propri pazienti , sarebbe a mio parere necessario fare un join con Nos_002 ed inserire "where PA_MEDI = 'xxxxxx'" (dati citati a memoria, qui non ho modo di controllare).
Guido

gennaro.tescione Mer 20 Giu 2012 - 1:16

alcuni giorni dopo aver ricevuto una circolare del distretto che diceva che le esenzioni E01-E03 E04 venivano automaticamente rinnovate,ho contattato MW e una operatrice in teleassistenza mi ha portato tutti i paziente con questi codici a scadenza del 31/03/2013.
Ho fatto un grosso guaio:l'80 % dei pazienti a cui ho rinnovato il tichet non risultavano negli elenchi del MEF!!
doppio lavoro..ma il problema piu grande e stato di dire a questi pazienti,a cui io avevo detto di non preoccuparsi....di rinnovare il tiket||||
gennaro

Doc.Raphael Mer 3 Ott 2012 - 0:07

Lucio Mignone ha scritto:Poiché in Toscana sono state automaticamente rinnovate le esenzioni E01,......

UPDATE DBA.cart_paz_ese SET dscdese = '2013-03-31'
WHERE dscdese = '2012-03-31' AND cod_ese = 'RE1' OR cod_ese = 'RE3' OR cod_ese = 'RE4';
commit;
select 'Comando eseguito con successo!' as Risultato;

Forse mi sono perso qualcosa....

Ho provato a far girare questa query ed anche un'altra ancora più spartana sul nuovo database di Millewin e, contrariamente al vecchio..... non funzionano.....

Come mai?

Certo il database è cambiato... I comandi SQL non vanno più? O forse c'è una password?

Ciao!

**Admin** Mer 3 Ott 2012 - 0:53

Doc.Raphael ha scritto:
Lucio Mignone ha scritto:Poiché in Toscana sono state automaticamente rinnovate le esenzioni E01,......

UPDATE DBA.cart_paz_ese SET dscdese = '2013-03-31'
WHERE dscdese = '2012-03-31' AND cod_ese = 'RE1' OR cod_ese = 'RE3' OR cod_ese = 'RE4';
commit;
select 'Comando eseguito con successo!' as Risultato;

Forse mi sono perso qualcosa....

Ho provato a far girare questa query ed anche un'altra ancora più spartana sul nuovo database di Millewin e, contrariamente al vecchio..... non funzionano.....

Come mai?

Certo il database è cambiato... I comandi SQL non vanno più? O forse c'è una password?

Ciao!

iL COMANDO AGGIORNA LE ESENZIONI E01, E03 ED E04 CON SCADENZA AL 31/03/2012 PORTANDOLA ALLA DATA 31/03/2013.

EVIDENTEMENTE LE DATE SONO SBAGLIATE.

Doc.Raphael Mer 3 Ott 2012 - 1:07

Admin ha scritto:
Doc.Raphael ha scritto:
Lucio Mignone ha scritto:Poiché in Toscana sono state automaticamente rinnovate le esenzioni E01,......

UPDATE DBA.cart_paz_ese SET dscdese = '2013-03-31'
WHERE dscdese = '2012-03-31' AND cod_ese = 'RE1' OR cod_ese = 'RE3' OR cod_ese = 'RE4';
commit;
select 'Comando eseguito con successo!' as Risultato;

Forse mi sono perso qualcosa....

Ho provato a far girare questa query ed anche un'altra ancora più spartana sul nuovo database di Millewin e, contrariamente al vecchio..... non funzionano.....

Come mai?

Certo il database è cambiato... I comandi SQL non vanno più? O forse c'è una password?

Ciao!

iL COMANDO AGGIORNA LE ESENZIONI E01, E03 ED E04 CON SCADENZA AL 31/03/2012 PORTANDOLA ALLA DATA 31/03/2013.

EVIDENTEMENTE LE DATE SONO SBAGLIATE.

Ovviamente la query era solo un esempio...... Le date e le modifiche erano quelle giuste (da noi in Campania le esenzioni E05, E08 e Farmaci per patologia cronica <22.000 Euro) sono state prorogate dal 30 settembre al 31 gennaio prossimo.

Per cui ho riscontrato che con il vecchio database l'SQL funziona regolarmente, mentre per il nuovo tipo di database che sta circolando le stesse query non vanno proprio....

Ciao!

**drtulino** Mer 3 Ott 2012 - 9:10

Doc.Raphael ha scritto:
Ovviamente la query era solo un esempio...... Le date e le modifiche erano quelle giuste (da noi in Campania le esenzioni E05, E08 e Farmaci per patologia cronica <22.000 Euro) sono state prorogate dal 30 settembre al 31 gennaio prossimo.
Per cui ho riscontrato che con il vecchio database l'SQL funziona regolarmente, mentre per il nuovo tipo di database che sta circolando le stesse query non vanno proprio....
Ciao!

Come nuovo DB Ti riferisci per caso al Postgres?

Doc.Raphael Mer 3 Ott 2012 - 9:15

drtulino ha scritto:
Doc.Raphael ha scritto:
Ovviamente la query era solo un esempio...... Le date e le modifiche erano quelle giuste (da noi in Campania le esenzioni E05, E08 e Farmaci per patologia cronica <22.000 Euro) sono state prorogate dal 30 settembre al 31 gennaio prossimo.
Per cui ho riscontrato che con il vecchio database l'SQL funziona regolarmente, mentre per il nuovo tipo di database che sta circolando le stesse query non vanno proprio....
Ciao!
Come nuovo DB Ti riferisci per caso al Postgres?

Si....

Lucio Mignone Mer 3 Ott 2012 - 9:48

Doc.Raphael ha scritto:
drtulino ha scritto:
Doc.Raphael ha scritto:
Ovviamente la query era solo un esempio...... Le date e le modifiche erano quelle giuste (da noi in Campania le esenzioni E05, E08 e Farmaci per patologia cronica <22.000 Euro) sono state prorogate dal 30 settembre al 31 gennaio prossimo.
Per cui ho riscontrato che con il vecchio database l'SQL funziona regolarmente, mentre per il nuovo tipo di database che sta circolando le stesse query non vanno proprio....
Ciao!
Come nuovo DB Ti riferisci per caso al Postgres?

Si....

La struttura del nuovo database rende le vecchie query inutilizzabili.
Andrebbero tutte modificate...

Doc.Raphael Mer 3 Ott 2012 - 10:10

Lucio Mignone ha scritto:
La struttura del nuovo database rende le vecchie query inutilizzabili.
Andrebbero tutte modificate...

E' quello che sospettavo...

C'è qualche "manuale" tipo quello per l'SQL?

Ciao!

**drtulino** Mer 3 Ott 2012 - 11:52

Lucio Mignone ha scritto:
Doc.Raphael ha scritto:
drtulino ha scritto:
Doc.Raphael ha scritto:
Ovviamente la query era solo un esempio...... Le date e le modifiche erano quelle giuste (da noi in Campania le esenzioni E05, E08 e Farmaci per patologia cronica <22.000 Euro) sono state prorogate dal 30 settembre al 31 gennaio prossimo.
Per cui ho riscontrato che con il vecchio database l'SQL funziona regolarmente, mentre per il nuovo tipo di database che sta circolando le stesse query non vanno proprio....
Ciao!
Come nuovo DB Ti riferisci per caso al Postgres?

Si....

La struttura del nuovo database rende le vecchie query inutilizzabili.
Andrebbero tutte modificate...

Esatto!!

Guido Mer 3 Ott 2012 - 12:25

Benissimo ! Si ricomincia a studiare daccapo tutto. Sad

Ad ogni modo, se accettate un consiglio dall'ultimo arrivato Wink

, ho visto che in parecchi quesiti si consiglia sempre di dare direttamente un comando UPDATE etc. senza che quindi ci sia la possibilita' di controllare in qualche modo se la query non dia risultati inaspettati.
Io direi che sarebbe meglio far precedere la query di UPDATE con una SELECT etc. piu' le stesse espressioni di filtro e Join dell' UPDATE.
Se il risultato e' quello corretto, procedere con l'UPDATE, dopodiche' si potra' ridare lo stesso comando SELECT precedente per controllare le differenze.
Inoltre ricordatevi che USERID di CART_PAZ_ESE o delle altre tabelle memorizza solo il codice dell'ultimo modificatore, quindi se un record e' stato modificato da un sostituto loggato con le sue credenziali, lo stesso record verrebbe tralasciato dalla modifica.
Scusate per l'impertinenza Very Happy

.

Guido

Lucio Mignone Mer 3 Ott 2012 - 15:27

Guido ha scritto:Benissimo ! Si ricomincia a studiare daccapo tutto.

Ad ogni modo, se accettate un consiglio dall'ultimo arrivato , ho visto che in parecchi quesiti si consiglia sempre di dare direttamente un comando UPDATE etc. senza che quindi ci sia la possibilita' di controllare in qualche modo se la query non dia risultati inaspettati.
Io direi che sarebbe meglio far precedere la query di UPDATE con una SELECT etc. piu' le stesse espressioni di filtro e Join dell' UPDATE.
Se il risultato e' quello corretto, procedere con l'UPDATE, dopodiche' si potra' ridare lo stesso comando SELECT precedente per controllare le differenze.
Inoltre ricordatevi che USERID di CART_PAZ_ESE o delle altre tabelle memorizza solo il codice dell'ultimo modificatore, quindi se un record e' stato modificato da un sostituto loggato con le sue credenziali, lo stesso record verrebbe tralasciato dalla modifica.
Scusate per l'impertinenza .

Guido

Guido,

il tuo suggerimento su UPDATE è OTTIMO e nessuno sinora ci aveva pensato!

Per quanto riguarda il nuovo database a prima vista le modifiche non sono sconvolgenti, esempio:
DBA.cart_accert diventa "public"."cart_accert" ed i nomi delle colonne sono gli stessi del vecchio database ma sempre fra virgolette.

Guido Mer 3 Ott 2012 - 23:33

Lucio Mignone ha scritto:

Guido,

il tuo suggerimento su UPDATE è OTTIMO e nessuno sinora ci aveva pensato!

Non ci credo ! Sei troppo buono ! Cool

Per quanto riguarda il nuovo database a prima vista le modifiche non sono sconvolgenti, esempio:
DBA.cart_accert diventa "public"."cart_accert" ed i nomi delle colonne sono gli stessi del vecchio database ma sempre fra virgolette.

Ah, benissimo, temevo che avessero cambiato i nomi delle tabelle e dei campi.
Tiro un sospiro di sollievo.
Grazie

Cambiando argomento da diversi giorni tento di contattare l'ssistenza per quei problemi che sai, ma dopo una ventina di minuti di attesa devo rinunciare.
Come stava suggerendo un collega nella mailing list di yahoo sarebbe utile almeno sapere quanti utenti sono in attesa. I tempi sono difficilmente stimabili perche' ci potrebbero essere quesiti da cinque minuti ed altri da mezz'ora, ma almeno si avrebbe un'idea.
Questo sistema era usato nel Call Center dell'Agenzia delle Entrate e debbo dire che era utile

Guido

Contenuto sponsorizzato

PROROGARE AUTOMATICAMENTE LE ESENZIONI E01 E03 E04

PROROGARE AUTOMATICAMENTE LE ESENZIONI E01 E03 E04

Re: PROROGARE AUTOMATICAMENTE LE ESENZIONI E01 E03 E04

Re: PROROGARE AUTOMATICAMENTE LE ESENZIONI E01 E03 E04

Re: PROROGARE AUTOMATICAMENTE LE ESENZIONI E01 E03 E04

Re: PROROGARE AUTOMATICAMENTE LE ESENZIONI E01 E03 E04

Re: PROROGARE AUTOMATICAMENTE LE ESENZIONI E01 E03 E04

Re: PROROGARE AUTOMATICAMENTE LE ESENZIONI E01 E03 E04

Re: PROROGARE AUTOMATICAMENTE LE ESENZIONI E01 E03 E04

Re: PROROGARE AUTOMATICAMENTE LE ESENZIONI E01 E03 E04

Re: PROROGARE AUTOMATICAMENTE LE ESENZIONI E01 E03 E04

Re: PROROGARE AUTOMATICAMENTE LE ESENZIONI E01 E03 E04

Re: PROROGARE AUTOMATICAMENTE LE ESENZIONI E01 E03 E04

Re: PROROGARE AUTOMATICAMENTE LE ESENZIONI E01 E03 E04

Re: PROROGARE AUTOMATICAMENTE LE ESENZIONI E01 E03 E04

Re: PROROGARE AUTOMATICAMENTE LE ESENZIONI E01 E03 E04

Re: PROROGARE AUTOMATICAMENTE LE ESENZIONI E01 E03 E04

Re: PROROGARE AUTOMATICAMENTE LE ESENZIONI E01 E03 E04

Re: PROROGARE AUTOMATICAMENTE LE ESENZIONI E01 E03 E04

Re: PROROGARE AUTOMATICAMENTE LE ESENZIONI E01 E03 E04

Re: PROROGARE AUTOMATICAMENTE LE ESENZIONI E01 E03 E04

Re: PROROGARE AUTOMATICAMENTE LE ESENZIONI E01 E03 E04

Re: PROROGARE AUTOMATICAMENTE LE ESENZIONI E01 E03 E04

Re: PROROGARE AUTOMATICAMENTE LE ESENZIONI E01 E03 E04

Re: PROROGARE AUTOMATICAMENTE LE ESENZIONI E01 E03 E04

Re: PROROGARE AUTOMATICAMENTE LE ESENZIONI E01 E03 E04

Re: PROROGARE AUTOMATICAMENTE LE ESENZIONI E01 E03 E04