Openfisca Managing Tool: a tool to manage fiscal sistems

Università degli studi di Camerino
Scuola di Scienze e Tecnologie
Corso di Laurea in Informatica (Classe L-31)
Openfisca Managing Tool: strumento per
la gestione di sistemi fiscali
Tesi sperimentale
Laureandi
Stacchio Lorenzo
Petrelli Corrado
Relatore
Prof. Polini Andrea
Correlatore
Prof. Esposito Roberto
Avv. Lonoce Antonino
Anno Accademico 2017/2018

Indice
1 Introduzione 2
2 Metodologie e strumenti di sviluppo 4
2.1 Sviluppo Open Source . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 La community . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.1 AgID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.2 DevelopersItalia . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Simulazione e Microsimulazione . . . . . . . . . . . . . . . . . . . . . 7
2.3.1 Definizione di Simulatore e Simulazione . . . . . . . . . . . . . 7
2.3.2 Microsimulazione . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 OpenFisca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.5 OpenFisca-italy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.6 OpenFisca-Management-Tool . . . . . . . . . . . . . . . . . . . . . . 9
2.7 Strumenti open-source utilizzati durante lo sviluppo . . . . . . . . . . 10
2.7.1 Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.7.2 Github . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.7.3 Slack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.7.4 GitKraken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.7.5 Atom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.7.6 CircleCI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.8 Linguaggi Utilizzati . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.8.1 Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.8.2 Pew . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.8.3 Python Kivy . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.8.4 GitHub Flavored Markdown . . . . . . . . . . . . . . . . . . . 16
3 OpenFisca 17
3.1 Struttura dello stack Openfisca . . . . . . . . . . . . . . . . . . . . . 17
3.2 Esempi di utilizzo di sistemi Openfisca . . . . . . . . . . . . . . . . . 18
3.3 Analisi dei requisiti e studio preliminare . . . . . . . . . . . . . . . . 19
3.4 Studio del core di Openfisca . . . . . . . . . . . . . . . . . . . . . . . 20
3.5 Studio della documentazione per sviluppare il country-package . . . . 21
3.6 Descrizione della documentazione per sviluppare il country-package . 21
3.7 Openfisca Core: Concetti chiave . . . . . . . . . . . . . . . . . . . . . 22
3.7.1 Sistema di tasse e benefici . . . . . . . . . . . . . . . . . . . . 22
3.7.2 Entità . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.7.3 Variabile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.7.4 Parametro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.7.5 Periodo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.7.6 Riforma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.7.7 Test per le variabili . . . . . . . . . . . . . . . . . . . . . . . . 23
3.7.8 Simulazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.8 Codifica del country-package: “Dalla legge al codice” . . . . . . . . . 23
3.8.1 Entità . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.8.2 Variabile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.8.3 Parametro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.8.4 Riforma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.8.5 Test per le variabili . . . . . . . . . . . . . . . . . . . . . . . . 33
3.8.6 Simulazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.8.7 Estensione dei file per la codifica . . . . . . . . . . . . . . . . 35
3.9 Flusso operativo della simulazione . . . . . . . . . . . . . . . . . . . . 36
3.9.1 Regione1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.9.2 Regione2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.9.3 Regione3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.10 Openfisca country-template . . . . . . . . . . . . . . . . . . . . . . . 39
3.10.1 Country-template . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.11 Contributo al progetto Openfisca . . . . . . . . . . . . . . . . . . . . 40
3.11.1 Contributo al country-template . . . . . . . . . . . . . . . . . 40
3.11.2 Contributo alla documentazione . . . . . . . . . . . . . . . . . 40
3.11.3 Contributo al core di OpenFisca . . . . . . . . . . . . . . . . . 41
4 OpenFisca Italy 43
4.1 Scelta della legislazione . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2 Nozioni teoriche IRPEF . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2.1 Definizione legislativa . . . . . . . . . . . . . . . . . . . . . . . 44
4.2.2 Struttura generale . . . . . . . . . . . . . . . . . . . . . . . . 44
4.3 Implementazione IRPEF . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.4 Nozioni teoriche IMU . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.4.1 Definizione legislativa . . . . . . . . . . . . . . . . . . . . . . . 50
4.4.2 Struttura generale . . . . . . . . . . . . . . . . . . . . . . . . 50
4.5 Implementazione IMU . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5 Openfisca Managing Tool 56
5.1 Scopo del software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.2 Funzionalità del software . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.3 Architettura del sistema . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.3.1 Regione 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.3.2 Regione 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.3.3 Regione 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.3.4 Regione 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.4 Dalla teoria alla pratica . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.4.1 Download and choose an openfisca system . . . . . . . . . . . 62
5.4.2 Home . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.4.3 Legislation Explorer . . . . . . . . . . . . . . . . . . . . . . . 64
5.4.4 Reform Maker . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.4.5 Simulation Maker . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.5 Openfisca Managing Tool: Manuale d’uso . . . . . . . . . . . . . . . . 68
5.5.1 Schermata Iniziale . . . . . . . . . . . . . . . . . . . . . . . . 68
5.5.2 Schermata Home . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.5.3 Schermata Visualizza Sistema . . . . . . . . . . . . . . . . . . 69
5.5.4 Schermata Effettua Riforme . . . . . . . . . . . . . . . . . . . 70
5.5.5 Schermata Effettua Simulazione . . . . . . . . . . . . . . . . . 77
5.6 Fattori esterni che causano il mal funzionamento del sistema . . . . . 82
5.6.1 Lunghezza massima del pathname su sistemi operativi Windows 82
5.6.2 Standardizzazione nella nomenclatura delle directory nei si-
stemi Openfisca . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.6.3 Problemi di versioning delle dipendenze tra i vari Openfisca . 83
5.7 Funzionalità future da implementare . . . . . . . . . . . . . . . . . . 84
5.7.1 Impossibilità di aggiungere e/o modificare Variabili di tipo
Enum nelle riforme . . . . . . . . . . . . . . . . . . . . . . . . 84
5.7.2 Mancanza di riferimenti alle Enumeration per Variabili di tipo
Enum in lettura . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.7.3 Parameter Reform . . . . . . . . . . . . . . . . . . . . . . . . 84
5.7.4 Parameter Node reader . . . . . . . . . . . . . . . . . . . . . . 84
6 Conclusioni 85
7 Ringraziamenti 87

Abstract
Diversi stati nel mondo hanno tempi per l’attuazione di procedimenti legisla-
tivi molto lunghi, che spesso non portano al risultato desiderato.
Per evitare ciò, si effettua una pianificazione strategica che non è sempre cos`ı
semplice da progettare e da verificare dato l’elevato numero di variabili da gestire.
Inoltre, una pianificazione strategica approfondita è molto costosa in termini di
tempo (che potrebbe essere dedicato all’attuazione dei procedimenti legislativi).
Proprio per i motivi sopracitati, è necessario rendere trasparente tale pianificazione
e poter valutare, in modo immediato, l’impatto che avrebbe un nuovo procedimento
legislativo su tutto il sistema.
Contribuisce a questo obiettivo OpenFisca (organizzazione governativa francese)
che è riuscita a sviluppare uno stack di moduli open-source in grado di definire
un sistema di tasse e benefici per ogni stato esistente. In questo contesto ci siamo
mossi per sviluppare il sistema di tasse e benefici italiano.
Successivamente, valutando le alte barriere professionali che impediscono l’utiliz-
zo del sistema ai non esperti nell’ambito informatico, abbiamo deciso di creare il
progetto Openfisca Managing Tool, che propone di essere un software multi-
piattaforma a interfaccia grafica per la gestione di un qualsiasi sistema di tasse e
benefici.
1

1. Introduzione
Alla base di questo documento vi è l’analisi dello stack di componenti open-
source del sistema Openfisca (sviluppato dall’omonima organizzazione) e l’analisi
delle problematiche relative al sistema stesso, che generano barriere professionali per
l’utilizzo.
In particolare, lo stack di componenti Openfisca consente di:
• Definire un sistema di tasse e benefici per ogni paese esistente al mondo;
• Effettuare delle simulazioni su di un qualsiasi sistema di tasse e benefici
già definito;
• Valutare l’impatto di una riforma su di un qualsiasi sistema di tasse e
benefici già definito.
Le motivazioni, che ci hanno spinto ad approfondire l’analisi dello stack di
componenti del sistema Openfisca, sono molteplici:
• L’interesse per il campo della microsimulazione del quale eravamo neofiti;
• Fornire al legislatore un software di microsimulazione econometrica, comple-
tamente open-source, per il sistema fiscale italiano;
• La nascita di rapporti internazionali con team di sviluppo da differenti paesi.
Nonostante le premesse, l’obiettivo di questa tesi non è solamente quello di fornire
un’analisi del sistema Openfisca, mettendo in evidenza sia le caratteristiche che
le problematiche, ma è anche quello di mostrare le scelte, organizzative ed ope-
rative adottate per lo sviluppo del sistema openfisca-italy (sfruttando il motore
Openfisca-Core) e del software Openfisca Managing Tool.
Nonostante la complessità del sistema openfisca-italy, questo non sarà l’argomen-
to centrale della tesi; lo è Il software ad interfaccia grafica, di nostra invenzione,
Openfisca Managing Tool il cui scopo è quello di fornire un’implementazione per
le seguenti operazioni:
• Visualizzazione del sistema di regolamenti legislativi 1
già definiti all’in-
terno di un sistema di tasse e benefici Openfisca;
1
I regolamenti legislativi si concretizzano in strutture che verranno definite nel capitolo relativo
ad Openfisca
2

• Definizione di riforme, che consentono la modifica dei regolamenti già
definiti e/o la definizione di nuovi regolamenti legislativi;
• Simulazioni sul sistema corrente e su di un sistema riformato.
Openfisca-italy ed Openfisca Managing Tool, sono stati progettati e sviluppati
adottando tecniche tipiche della metodologia AGILE, effettuando revisioni continue
dei prototipi creati con il team Openfisca. Sono state anche adottate tecniche per
la facilitazione dell’internazionalizzazione del sistema.
Il linguaggio di codifica scelto è Python 2.7 (necessario per sviluppare un qualunque
sistema openfisca) accoppiato con il framework Python Kivy.
La tesi è articolata in quattro capitoli:
1. Nel primo capitolo, viene fornita una descrizione, abbastanza dettagliata
delle metodologie e degli strumenti utilizzati per sviluppare sia il sistema
Openfisca-italy che il software Openfisca Managing Tool;
2. Nel secondo capitolo, viene descritto l’ecosistema Openfisca, dettagliando
particolarmente la struttura, l’implementazione dei vari elementi giuridici e
come utilizzarli per sviluppare un generico sistema di tasse e benefici;
3. Nel terzo capitolo, vengono discusse le scelte, organizzative ed operative,
prese per definire ed implementare il sistema di tasse e benefici per lo stato
italiano descrivendo anche gli obiettivi raggiunti a livello implementativo;
4. Nel quarto ed ultimo capitolo, viene descritto il processo di sviluppo del
software Openfisca Managing Tool. Verranno discusse l’l’architettura, le
funzionalità attualmente presenti e gli sviluppi futuri.
3

2. Metodologie e strumenti di svi-
luppo
In questo capitolo, discuteremo:
• Del mondo Open-source e della nostra partecipazione alle varie community
durante lo sviluppo del sistema Openfisca-italy ed il software Openfisca
Managing Tool;
• Della teoria della simulazione e dell’ecosistema Openfisca;
• Gli approcci e gli strumenti utilizzati per sviluppare il sistema Openfisca-
italy ed il software Openfisca Managing Tool.
2.1 Sviluppo Open Source
In informatica, il termine open source viene utilizzato per riferirsi ad un soft-
ware di cui gli autori rendono pubblico il codice sorgente, favorendone il libe-
ro studio e permettendo a programmatori indipendenti di apportarvi modifiche ed
estensioni [1].
Questo non significa necessariamente che il software open source sia gratuito per
chiunque: a seconda della licenza che lo accompagna, il codice sorgente può essere
rilasciato dallo sviluppatore solo a scopo di ispezione (frequente nell’ambito dei soft-
ware di crittografia), per favorire l’integrazione con altri software aziendali, a scopo
di studio e ricerca ma non per utilizzi commerciali [2].
A primo impatto, si potrebbe pensare che l’approccio open source sia nato con l’o-
biettivo di produrre e/o migliorare software in maniera totalmente gratuita, in realtà
lo scopo dell’open source è quello di “permettere la collaborazione tra persone, con
abilità e conoscenze differenti, riuscendo a raggiungere obiettivi che non si potrebbe-
ro raggiungere in nessun altro modo”[3].
A discapito delle aspettative, ci sono vari modi per guadagnare tramite proget-
ti open-source, ad esempio, una raccolta fondi tramite piattaforme di crowdfun-
ding[4] per finanziare un progetto.
Esempi di software con licenze open source, giusto per citarne alcuni, sono:
• Libre Office: suite di applicazioni che offre servizi di tipo office automation;
• Gimp: editor di immagini;
4

• Mozilla Firefox: web browser;
• Sistemi Operativi GNU linux: Gentoo, Debian, Ubuntu....
Lo sviluppo open source ha subito un forte incremento nel primo decennio del 2000,
anche grazie alla nascita di strumenti come Git e piattaforme come Github (di-
scussi rispettivamente nelle sezioni 2.7.1 e 2.7.2); esistono, infatti, più di 57 milioni
di repository (ossia progetti) solamente all’interno della piattaforma appena citata.
(a) Firefox. (b) VLC. (c) 7-zip. (d) Ubuntu.
Fig. 2.1: Progetti open-source
2.2 La community
La community è un gruppo di persone che partecipano a discussioni on-line per
raggiungere un fine comune. In particolare, esistono community Open-source
che si occupano della gestione e lo sviluppo di progetti.
Durante lo sviluppo dei vari progetti, abbiamo aderito a due community Open-
source:
• “Team per l’Italia in digitale” che ha come obiettivo quello di digitaliz-
zare la Pubblica Amministrazione italiana;
• OpenFisca, nata per supportare gli sviluppatori con la definizione di nuovi
sistemi fiscali.
2.2.1 AgID
L’Agenzia per l’Italia in Digitale è un’azienda pubblica, vigilata dal Presidente
del Consiglio dei Ministri, che ha lo scopo di innovare tecnologicamente la pubblica
amministrazione ed i servizi forniti alle aziende ed ai cittadini.
2.2.1.1 Competenze e Funzioni
Questa azienda ha lo scopo di seguire l’Agenda digitale per l’Europa (DAE)
creata nel maggio 2010, quest’ultilma si propone di aiutare le imprese ed i cittadini
ad ottenere il massimo dalle tecnologie digitali. Proprio dalla DAE nasce l’Agenda
digitale per l’Italia che fornisce all’AgID le seguenti competenze e funzioni:
• Migliorare tecnologie e servizi per la crescita economica e sociale del Paese, ad
esempio centralizzando l’accesso ai servizi dei cittadini attraverso SPID[5];
5

• Dirigere ed organizzare le attività del CERT (un’organizzazione che ha lo
scopo di raccogliere le vulnerabilità software e gli incidenti informatici) della
Pubblica Amministrazione;
• Promuovere lo sviluppo di comunità intelligenti, ad esempio: aiutare la diffu-
sione della banda ultralarga[6] in Italia;
• Promuovere l’alfabetizzazione digitale;
• Coordinare e progettare iniziative strategiche di interesse nazionale per l’ero-
gazione efficiente di servizi in rete;
• Dettare regole tecniche, linee guida, metodologie progettuali in materia di
tecnologie informatiche e rendere omogenei i sistemi informativi pubblici in
tutto il Paese;
• Emanare pareri interpretativi riguardo le nuove regole (ad esempio: Codice
dell’amministrazione digitale) e le metodologie di sicurezza per le pubbli-
che amministrazioni (ad esempio: Misure minime di sicurezza ICT per
le pubbliche amministrazioni).
2.2.2 DevelopersItalia
È una piattaforma open source, nata dalla collaborazione del-
l’AgID ed il Team per la Trasformazione Digitale, che gestisce i
principali progetti tecnologici in sviluppo nel Paese.
2.2.2.1 Competenze e Funzioni
Questa piattaforma ha lo scopo di organizzare e gestire pro-
getti open source, e di aiutare gli sviluppatori intenti a implementarli. Tra i vari
progetti, gestiti da Developers Italia, ci sono:
• SPID (Sistema Pubblico di Identità Digitale): un nuovo sistema di login che
permette di accedere ai servizi online forniti dalla Pubblica Amministrazione
con un’unica identità digitale;
• ANPR (Anagrafe Nazionale della Popolazione Residente): è una banca dati
anagrafica nazionale che ha lo scopo di semplificare la burocrazia e migliorare i
servizi dei cittadini riguardanti: residenza, domicilio... (per esempio: il cambio
di residenza);
• dati.gov.it: è un catalogo di Open Data della Pubblica Amministrazione che
ha fatto in modo di centralizzare i dati forniti e renderli disponibili al pubblico;
(a) SPID (b) ANPR (c) dati.gov.it
Fig. 2.2: Progetti
6

2.3 Simulazione e Microsimulazione
Nelle successive sezioni, parleremo dei sistemi Openfisca, che verranno definiti
come software di microsimulazione economica. E’ doveroso, quindi, definire i
concetti di simulazione e microsimulazione per poter proseguire la lettura del
documento.
2.3.1 Definizione di Simulatore e Simulazione
Un simulatore è un dispositivo o un ambiente, che riproduce un particolare
modello concreto o astratto della realtà, sul quale possono essere effettuate delle
simulazioni [7].
Un esempio di modello concreto é il modello in scala di una nave che viene poi posto
in un’apposita vasca per effettuare prove simulate allo scopo di stimare opportune
misure di prestazione.
Per il lettore esperto in Scienze dell’informazione automatica, ed in particolare della
programmazione ad oggetti, è facile fare un’assonanza tra i concetti di <Insieme
di classi di un programma-oggetti creati sulle classi> e <Simulatore-
simulazioni>.
L’insieme delle classi di un programma formano l’ambiente in cui gli oggetti e
le variabili prendono vita, assumendo un comportamento in base alle defi-
nizioni poste dal programmatore.
Per il simulatore il concetto è del tutto simile: il simulatore definisce l’ambiente
ed il modello di base (un po’ come se fosse un insieme di classi) che grazie alle
varie simulazioni prendono vita assumendo comportamenti differenti (un po’ come
differenti oggetti che vengono creati a partire dalla stessa classe).
Riprendendo l’esempio descritto poco fa, il modello a scala della nave e della
vasca formano l’ambiente fissato creato dal simulatore (come fosse una classe),
mentre nelle simulazioni, create a partire dal simulatore in esame, vengono definiti
attributi quali la quantità d’acqua nella vasca, il peso e la forma della nave,
che saranno differenti per ogni simulazione generata (come le istanziazioni di
vari oggetti).
Per poter definire un Simulatore, bisogna seguire una serie di step:
1. ANALISI DEL PROBLEMA
Vengono considerati gli obiettivi e le problematiche da esaminare e viene fatta
un’analisi di fattibilità per circoscrivere il problema da prendere in esame (per
esempio la simulazione di un volo deve tener conto di differenti variabili e varie
problematiche, ma alcune possono essere trascurate);
2. FORMULAZIONE DEL MODELLO DI SIMULAZIONE
Viene steso un modello concettuale dove vengono definiti i flussi delle informa-
zioni del problema preso in considerazione. Questo modello viene poi valutato
per verificare se offre un’immagine consistente della realtà (è possibile che
venga definito un modello con variabili errate o non congruenti);
3. ANALISI DEI DATI IN INGRESSO
Vengono raccolti dei dati di ingresso che verranno considerati come para-
metri di funzionamento del sistema dopo opportune trasformazioni (vengono
applicate diverse tecniche econometriche, probabilistiche e statistiche);
7

4. VALIDAZIONE DEL MODELLO
Il modello concettuale viene convertito in modello matematico che viene, in
seguito, dimostrato;
5. TESTING
In questa fase, vengono pianificati dei test per ogni iterazione di sviluppo del
Simulatore, per evidenziare la sua validità nel tempo;
6. ANALISI DEI DATI IN USCITA
Nell’ultima fase vengono definiti dei dati di uscita attesi, che vengono com-
parati ai risultati forniti dal simulatore (accettando risultati differenti con un
certo margine di errore).
2.3.2 Microsimulazione
Il termine Microsimulazione deriva dall’inglese “Microanalytics Simulation”,
e viene definita come una sottocategoria della Simulazione che fa uso di strumenti
analitici computerizzati che eseguono analisi altamente dettagliate di attività come
il traffico stradale in un incrocio, transazioni finanziarie o agenti patogeni che dif-
fondono malattie attraverso una popolazione [8].
La microsimulazione viene spesso utilizzata per valutare gli effetti degli interventi
proposti, prima che vengano implementati nel mondo reale.
Nei vari sistemi Openfisca, la microsimulazione viene utilizzata per valutare l’im-
patto di una Riforma su di un sistema fiscale prima che questa venga attuata
tramite un procedimento legislativo, si parla quindi di Microsimulazione Econo-
metrica.
Esistono differenti tipologie di microsimulazione:
• Microsimulazione econometrica
Permette di effettuare simulazioni economiche cos`ı da predire delle situazioni.
Un esempio di utilizzo potrebbe essere la misurazione dell’impatto di una
riforma nel sistema economico italiano;
• Microsimulazione del traffico
Permette di effettuare simulazioni sul traffico. Utilizzata moltissimo da inge-
gneri civili per valutare, ad esempio, la viabilità della strada inserendo una
rotatoria o un semaforo in un incrocio;
• Microsimulazione pedonale/di folla
Permette di effettuare simulazioni sul comportamento delle persone in mol-
ti ambiti, ad esempio, è possibile utilizzare questa tipologia per scegliere la
posizione delle uscite antincendio in una biblioteca;
• Microsimulazione nelle scienze della salute
Permette di effettuare simulazione sulla distribuzione dei microrganismi, ad
esempio si può visualizzare la diffusione di una determinata malattia;
• Microsimulazione spaziale
Permette di misurare il cambiamento di varie entità nello spazio in differenti
periodi temporali.
8

2.4 OpenFisca
Openfisca è una community nata in Francia nel 2015 con lo scopo di creare un
software open source di microsimulazione economica (denominato anch’esso
OpenFisca) che consenta di:
• Definire un sistema di tasse e benefici per un determinato paese;
• Effettuare delle simulazioni sul sistema definito utilizzando la normativa in
vigore;
• Definire riforme sul sistema corrente e valutarne l’impatto tramite Simulazioni.
I repositories dei vari progetti software, gestiti dalla community OpenFisca, sono
disponibili al seguente link https://github.com/openfisca/.
2.5 OpenFisca-italy
Il 30 aprile 2018, dalla collaborazione tra Lorenzo Stacchio, Corrado petrelli e
l’Università di Camerino con le community Developers Italia e Openfisca, nasce
il progetto tutto italiano denominato OpenFisca-Italy dopo aver tenuto varie di-
scussioni con i leader delle community.
Lo scopo del progetto Openfisca-italy è quello di fornire un simulatore che per-
metta:
• Al legislatore di avere un supporto per visualizzare l’impatto di una nuova
riforma sul sistema corrente;
• Agli sviluppatori di applicazioni Web/Desktop/Mobile di costruire un’inter-
faccia grafica che agevoli l’uso del simulatore per cittadini e giuristi.
Lo sviluppo e la struttura del progetto, verranno dettagliati nei capitoli 3 e 4.
2.6 OpenFisca-Management-Tool
Il 1 giugno 2018, da un’idea di Lorenzo Stacchio e Corrado Petrelli, nasce il pro-
getto software Openfisca-Managing-Tool, approvato dalla community Openfi-
sca.
Lo scopo del progetto Openfisca-Managing-Tool è quello di fornire un software
multi-piattaforma ad interfaccia grafica, che consenta di manipolare un generico si-
stema Openfisca-NameOfCountry.
In particolare questo software consente di:
• Visualizzare il sistema di regolamenti legislativi già definiti;
• Definire nuove riforme che consentono la modifica dei regolamenti già
definiti e/o la definizione di nuovi regolamenti legislativi;
• Effettuare simulazioni sul sistema corrente e/o su di un sistema riformato.
Lo sviluppo e la struttura del progetto, verranno dettagliati nel capitolo 5.
9

2.7 Strumenti open-source utilizzati durante lo
sviluppo
In questa sezione verranno elencati e dettagliati, tutti gli strumenti open-source
utilizzati durante lo sviluppo del sistema openfisca-italy e del software Openfisca-
Managing-Tool.
2.7.1 Git
Git è un software di controllo di versione distribuito a riga di comando,
nato nel 2005 che venne creato per facilitare lo sviluppo del kernel di Linux da parte
di numerosi sviluppatori provenienti da tutto il mondo.
Fig. 2.3: Logo di Git.
Git nacque perché, a quei tempi, BitKeeper (un software analogo a Git) cam-
biò licenza e divenne un software proprietario.
Col passare del tempo, Git divenne sempre più usato perché permetteva di modi-
ficare e sviluppare iterativamente progetti code-based in un ambiente flessibile, e
di condividere il codice con i propri collaboratori in maniera istantanea con il solo
ausilio di una connessione internet.
Questo ha consentito, di evitare la condivisione del codice tramite dispositivi di
memoria di massa esterni che risultava oneroso a causa dei prezzi e dell’affidabilità.
2.7.2 Github
GitHub è principalmente un servizio di hosting per repository Git, lanciato nel
2009, che può anche esser visto come una piattaforma sociale, dove gli utenti pos-
sono collaborare in qualunque progetto pubblico presente sulla piattaforma.
La collaborazione libera sui vari progetti presenti nella piattaforma, consente di rag-
giungere obiettivi prima irrealizzabili e di imparare studiando i progetti
altrui.
Fig. 2.4: Logo di Github
10

2.7.3 Slack
Fig. 2.5: Logo di
Slack
Slack è una piattaforma di messaggistica costruita per i
team che permette di integrare differenti canali di comunica-
zione in un unico servizio.
Molto utilizzata dai team di sviluppo per la facilità di con-
divisione del codice e per i numerosi strumenti di supporto
alla comunicazione integrati nella piattaforma (videochiama-
ta, riferimenti...); tantoché l’obiettivo della piattaforma è
quello di organizzare e migliorare l’esperienza in team, consolidando e dando senso
ad un enorme flusso di dati che altrimenti sarebbero non-strutturati.
2.7.3.1 Perché usare slack?
Slack, oltre a permettere la creazione di canali, consente di integrare servizi ester-
ni tra cui: Google Drive (per l’archiviazione di file condivisi), Trello (per la gestione
dei task), GitHub (per la gestione dei repository) e Smooz (per la connessione di
Team differenti).
Inoltre, centralizza la comunicazione in una singola applicazione migliorando la pro-
duttività, infatti, è possibile: condividere file, comunicare privatamente o ad un
insieme preciso di persone (presenti in un canale privato o creando una chat di
gruppo) ed eseguirlo su qualunque dispositivo (PC, Smartphone e Tablet).
11

2.7.4 GitKraken
GitKraken è un Git client ad interfaccia grafica, che fornisce servizi quali:
• Un’integrazione completa con Github.com e Bitbucket.com per l’hosting di
repository git. Questa integrazione permette di eseguire tutte le operazioni
normalmente effettuate tramite riga di comando, ma con un’interfaccia grafica
intuitiva e un’automatizzazione del processo di autenticazione;
• Una rappresentazione grafica dei branch, dei commit e dei tag permet-
tendo cos`ı agli utenti di visualizzare il flusso del lavoro svolto;
• Una rappresentazione grafica dei conflitti durante l’azione di Merging
permettendo la scelta del codice in conflitto che si vuole accettare.
2.7.4.1 Scelta del Client
Esistono moltissimi client Git, molto simili tra loro.
È stato scelto GitKraken perché non richiede ulteriori registrazioni a siti (cosa ri-
chiesta da SourceTree, suo principale concorrente) e perché ha una grafica curata e
comprensibile anche da un neofita.
Fig. 2.6: Screenshot di GitKraken[9].
12

2.7.5 Atom
Atom è un IDE open-source multi-piattaforma basato su Chromium, ed è perciò
eseguibile su qualunque Sistema Operativo che supporti Chromium.
Fig. 2.7: Logo di Atom.
Atom possiede caratteristiche analoghe a quelle di molti altri editor di codice (in-
tegrazione di pacchetti aggiuntivi, integrazione con Git...) ma abbiamo constatato,
dopo vari mesi di utilizzo, che possiede:
• Performance più elevate rispetto ai vari concorrenti;
• Minor consumo di risorse (RAM e CPU);
• Maggiori performance dell’intelligence;
• Assenza dei bug riscontrati, precedentemente, con altri editor (Visual Studio
Code), utilizzando il simulatore Openfisca.
Per questi motivi lo reputiamo un ottimo editor per sviluppare un sistema openfisca
ed, in generale, un progetto Python-based.
2.7.6 CircleCI
Fig. 2.8: Logo di
CircleCI.
È una piattaforma di integrazione continua di software usata
quando si lavora con team di sviluppo avente molti contributori.
Viene utilizzata perché racchiude metodologie utili per:
• Evitare errori nel repository;
• Avere un codice più leggibile (è possibile definire uno stile
di indentazione predefinito cosicché i programmatori siano
costretti ad indentare in un determinato modo);
• Rendere operativo il progetto, automatizzando una serie
di passaggi che altrimenti sarebbero dovuti esser fatti ma-
nualmente dal programmatore (ad esempio: testing delle
funzionalità).
Permette, inoltre, l’integrazione con GitHub: ad ogni Pull Request verrà lanciato
uno script su uno o più container (in cui vengono eseguiti ambienti virtuali con risorse
mutualmente esclusive per testare il codice) creato su CircleCI; successivamente
verranno eseguiti tutti i test e tutti i controlli contenuti nello script per poi fornire
l’esito della computazione direttamente sulla Pull Request mittente, cos`ı facendo la
revisione del codice in fase di testing di nuove funzionalità risulta molto più agevole.
13

2.8 Linguaggi Utilizzati
In questa sezione verranno illustrati i linguaggi utilizzati durante il progetto.
2.8.1 Python
Python è un linguaggio di programmazione ad
alto livello multi-paradigma, permette infatti la pro-
grammazione orientata ad oggetti, la programmazione
strutturata ed alcune caratteristiche di programmazio-
ne funzionale (come le lambda expressions).
Oggigiorno questo linguaggio presenta una crescita espo-
nenziale, si pensa infatti che nei prossimi 5 anni sarà tra i 3 linguaggi più utilizzati
al mondo grazie alla facilità che i neofiti trovano nell’impararlo rispetto a Java [10].
Per fare un confronto, possiamo vedere come Python, nei codici sottostanti, per-
metta di scrivere codice più snello, comprensibile e semanticamente uguale a Java
[11].
(a) Codice in Python (b) Codice in Java
Fig. 2.9: Codici a confronto
Inoltre, possiamo notare come nell’indice TIOBE (l’indice dei più popolari soft-
ware redatto dall’azienda TIOBE, leader nel campo del controllo di qualità dei
software)[12] sia evidente l’enorme crescita annuale di Python rispetto a Java.
Fig. 2.10: Java vs Python - Aprile 2018.
14

2.8.1.1 Possibili utilizzi di Python
• Programmazione GUI: grazie a Tkinter, PyGtk e wxPython e framework
quali Python Kivy e PyQt;
• Sviluppo Web: mediante l’utilizzo di framework come Django;
• Sviluppo di sistemi di controllo (sviluppati anche dalla NASA[13]);
• Data Science: grazie alle numerose librerie contenute in SciPy;
• Internet Of Things: consente di programmare dispositivi IoT (Raspberry
Pi).
2.8.1.2 Utilizzi di Python all’interno del progetto
Python è stato utilizzato per sviluppare sia il sistema Openfisca-italy sia la
logica del software Openfisca-Managing-Tool.
2.8.1.3 Perché è stato scelto Python?
Il linguaggio Python è stato scelto per vari motivi:
• E’ un linguaggio facile da imparare, fattore fondamentale dato che, per contri-
buire a questo progetto, sono necessarie sia nozioni informatiche che tributarie.
Questa facilità di utilizzo, consente ad un tributarista di contribuire al progetto
pur affrontando qualche difficoltà iniziale.
• Ha molte librerie integrabili per elaborazioni complesse. Il motore di sistemi
Openfisca, infatti, sfrutta appieno la libreria NumPy, che è il pacchetto fon-
damentale per effettuare elaborazioni scientifiche su grandi quantità di dati
[14].
• Ha strumenti per la creazione e gestione di ambienti virtuali, in particolare,
Pew, descritto nella prossima sezione.
2.8.2 Pew
Pew, acronimo di Python Enviroment Wrapper[15] è un insieme di comandi che
permette la gestione di ambienti virtuali.
2.8.2.1 Definizione di ambiente virtuale
È un ambiente di sviluppo isolato che contiene librerie di una determinata ver-
sione, per esempio un nostro programma richiede l’utilizzo della libreria X nella
versione Y, invece un altro programma richiede sempre la libreria X ma nella ver-
sione Z.
Non sappiamo se la versione Z ha deprecato qualche funzione presente nella versione
Y (o viceversa) quindi per non avere errori si preferisce creare due ambienti virtuali
differenti cosicché ambedue gli applicativi possano funzionare senza problemi.
15

2.8.2.2 Utilizzo di Pew in Openfisca
Pew viene utilizzato per far eseguire il simulatore di un determinato paese. La
procedura per l’installazione e il modus operandi per far eseguire il simulatore è
ampiamente dettagliato al seguente link: https://goo.gl/Ut5tYi.
2.8.3 Python Kivy
Python Kivy è una libreria open-source per il
rapido sviluppo di applicazioni che fanno uso di
interfacce grafiche innovative [16]. In particolare
Python Kivy, è stato scelto in quanto è:
• Cross-platform, infatti lo stesso codice può essere
eseguito su Linux, Windows, Os X, Android, iOS e
Raspberry Pi;
• Business Friendly, Python Kivy è sotto licen-
za MIT ed è quindi open-source al 100%, inoltre è
stabile e fornito di una discreta documentazione;
• Basato sull’elaborazione accelerata tramite
GPU, infatti il motore grafico è costruito su OpenGL ES 2, che utilizza una pi-
peline grafica, moderna e veloce, che viene eseguita in modalità Elaborazione
accelerata tramite GPU1
.
2.8.4 GitHub Flavored Markdown
Per utilizzare al meglio la piattaforma di Versioning Github, bisogna stilare
dei documenti accessori al codice, come supporto alla navigazione nella storia del
progetto. Questi documenti sono solitamente:
• I file README, che possono essere o meno aggiornati ad ogni commit, che
spiegano il contenuto di una cartella o dell’intero progetto;
• I file di CHANGELOG, che servono per conoscere le nuove features o cam-
biamenti effettuati riferendosi a una certa versione del software.
Per scrivere questi documenti, è necessario conoscere il linguaggio di markdown
esteso da Github.
1
L’elaborazione accelerata tramite GPU consiste nello sfruttare una GPU affiancata ad
una CPU per facilitare operazioni di tipo CPU bound [17].
16

3. OpenFisca
In questa sezione, verrà discusso la struttura dello stack di componenti del siste-
ma Openfisca e verranno analizzati, utilizzando la documentazione come supporto,
i vari elementi che compongono la componente “kernel” dello stack (Openfisca-
Core) ed i modi, per utilizzare questi elementi, al fine di implementare un sistema
di tasse e benefici.
Verranno, inoltre, discussi sia i contributi forniti alla community ed ai vari progetti
Openfisca, sia il progetto openfisca-country template, che consente di inizializ-
zare un sistema di tasse e benefici in pochi istanti.
3.1 Struttura dello stack Openfisca
Fig. 3.1: Stack OpenFisca
Sotto un punto di vista architetturale, Openfisca è formato da uno stack di com-
ponenti. Ogni componente permette allo sviluppatore di focalizzarsi su un determi-
nato obiettivo senza intaccare le restanti parti (segue il principio di modularità
del software) [18].
Le componenti, che formano lo stack dell’ecosistema OpenFisca, sono:
• OpenFisca-Core, è la componente “kernel”, che contiene le funzioni princi-
pali (creazione di variabili, simulazioni...) utilizzate per sviluppare un sistema
di tasse e benefici;
• OpenFisca-NameOfCountry è la componente che sfrutta le funzioni pre-
senti Openfisca-Core per definire un sistema di tasse e benefici (ad esempio
OpenFisca-Italy, ne esiste uno per ogni stato).
17

Per velocizzare il processo di istanziazione del sistema è stato definito il proget-
to OpenFisca-CountryTemplate (https://github.com/openfisca/
country-template), che contiene una struttura gerarchica di base e vari
esempi per iniziare a sviluppare il sistema fiscale di riferimento;
• OpenFisca-NameOfExtension è una componente aggiuntiva opzionale che
si sovrappone al OpenFisca-NameOfCountry e che offre ulteriori funzio-
nalità e specifiche di una certa regione/città del paese di riferimento. Un
esempio di instanza di OpenFisca-NameOfExtension sono le regioni a
statuto speciale.
• Web API è la componente che consente di richiamare le varie funzioni, definite
all’interno sia del core che del country template, tramite utilizzo di Web Api.
Lo scopo di questa componente è, per lo più, di supporto alla creazione di
applicazioni web.
3.2 Esempi di utilizzo di sistemi Openfisca
La community francese ha, per ora, utilizzato il sistema Openfisca-france,
interfacciandosi tramite Web API per costruire tre applicazioni web:
• Consultazione dei parametri e delle variabili del sistema francese
Fig. 3.2: Ricerca delle variabili e parametri riguardanti il Salario.
L’applicazione è reperibile al seguente link: https://fr.openfisca.org/legislation.
• Simulatore di benefici sociali francesi
L’applicativo in questione valuta, a seconda degli input forniti nei vari form
presentati, se si ha diritto ad usufruire di alcuni benefici fiscali. Nell’immagine
sottostante è presente il risultato della simulazione, si noti che il soggetto ha
diritto ai benefici fiscali riguardante l’energia elettrica pari a 144€/anno.
18

Fig. 3.3: Risultato del simulatore di benefici sociali francesi.
L’applicazione è reperibile al seguente link: https://mes-aides.gouv.
fr/.
• Simulatore dell’impatto fiscale causato dal divorzio
Fornendo in input le persone fisiche coinvolte, la situazione familiare prima e
dopo il divorzio, il simulatore permette di visualizzare la ridistribuzione delle
ricchezze su ciascun componente. L’applicazione è reperibile al seguente link:
https://pa-comp.firebaseapp.com/.
3.3 Analisi dei requisiti e studio preliminare
Prima di iniziare la fase di analisi del problema (come costruire il sistema
fiscale italiano), ci siamo chiesti quali strumenti fossero necessari, per studiare ed
apprendere, le tecniche di sviluppo richieste al fine di codificare il sistema di tasse e
benefici italiano.
Dopo aver discusso con il rappresentante del team Developers Italia, accompagna-
ta da una prima lettura del codice delle varie repository che compongono il sistema
Openfisca, abbiamo constatato che gli strumenti da studiare fossero:
• Linguaggio di programmazione Python;
• Software versioning Git;
• Architettura e componenti di Openfisca-Core;
• Documentazione relativa allo sviluppo del country-package;
• Legislazione Italiana.
Gli strumenti utilizzati sono stati ampiamenti discussi nella Sezione 2.7 e nella
Sezione 2.8. Non sono stati, però, descritti importanti manufatti quali la docu-
mentazione relativa allo sviluppo del country-package e l’architettura del core
di Openfisca. Nelle prossime sezioni ci concentreremo sull’analisi e la descrizione
di quest’ultime.
19

3.4 Studio del core di Openfisca
Si dice che “un buon programmatore, prima di sviluppare un qualsiasi
software, studi la macchina e/o il sistema operativo su cui quest’ultimo
verrà eseguito”, per questo, prima di studiare la documentazione di sviluppo
del country-package italiano, sono state apprese le funzioni principali del core di
openfisca.
Lo studio del core è stato lungo e complesso ma, in compenso, ha apportato una
maggior consapevolezza e ci ha fatto comprendere molte delle scelte prese dal team
di sviluppo. Segue un class diagram, derivato dallo studio di Openfisca-core, che
riassume le componenti nello stesso e le loro correlazioni.
20

3.5 Studio della documentazione per sviluppare il
country-package
Per poter codificare il sistema di tasse e benefici italiano è stato necessario lo
studio della documentazione, a volte ambigua, fornita dagli sviluppatori (https:
//openfisca.org/doc/key-concepts.html).
Durante questa fase, c’è stata una comunicazione continua con il team di svilup-
po di Openfisca, grazie alla quale, abbiamo chiarito dubbi riguardo la documenta-
zione e suggerito alcune migliorie che potevano essere apportate al progetto e alla
documentazione stessa (discusse nella Sezione 3.11).
3.6 Descrizione della documentazione per svilup-
pare il country-package
La documentazione è suddivisa in otto sezioni:
• Concetti chiave;
• Dalla legge al codice;
• Openfisca Web Api;
• Risoluzione dei problemi;
• Istruzioni per l’utilizzo di Openfisca;
• Pubblicare i risultati;
• Community;
• Come contribuire al progetto Openfisca.
Questa documentazione spiega, in maniera a volte poco dettagliata, come sfruttare
le componenti fornite da openfisca-core per sviluppare un generico sistema di
tasse e benefici.
Dato che sarebbe prolisso e tedioso descrivere tutte le sezioni in maniera specifica,
concentreremo la nostra attenzione sulle sezioni ritenute di maggior rilievo, ossia la
sezione Concetti chiave e la sezione Dalla legge al codice.
21

3.7 Openfisca Core: Concetti chiave
I concetti chiave del sistema Openfisca sono stati generalizzati, affinché potessero
adattarsi a qualsiasi (o quasi) legislazione esistente.
3.7.1 Sistema di tasse e benefici
Il primo concetto chiave è quello del Sistema di tasse e benefici che rappre-
senta l’insieme delle variabili e dei parametri esistenti. Prima di capire cosa siano
le variabili ed i parametri, bisogna definire cosa sia un’entità.
3.7.2 Entità
Un’entità non è altro che un soggetto, sia esso fisico o giuridico, che possiede da
0 ad n variabili. Esempi di entità potrebbero essere Persona fisica e Persona giuri-
dica. Le entità possono essere raggruppate creando cos`ı quella che viene definita
come entità raggruppata. Esempi di entità raggruppate sono: famiglia, gruppi
aziendali etc..
3.7.3 Variabile
Una variabile:
• È una proprietà di un’entità;
• Può appartenere ad un’unica entità (ma non è vero il contrario);
• Può assumere un valore calcolato tramite una formula (che è definita all’interno
della variabile stessa) o passato in input (proprio per questo motivo sono sorti
dei problemi che verranno spiegati nella Sezione 3.11.3).
3.7.4 Parametro
Un parametro è una proprietà numerica della legislazione che può evolvere nel
tempo, ma a differenza di una variabile, questo non appartiene a nessuna entità.
I parametri vengono solitamente usati nelle formule per calcolare delle variabili.
3.7.5 Periodo
Ogni parametro o variabile assume un valore per un certo periodo che sia
esso mensile o annuale (o infinito nel caso in cui la variabile sia una costante).
3.7.6 Riforma
Un altro concetto da esprimere è sicuramente quello della Riforma.
Una Riforma può essere applicata in una simulazione per capire gli effetti di un
cambiamento apportato ad una formula di una variabile o ad un parametro esistente.
22

3.7.7 Test per le variabili
I test per le variabili sono particolari file, che consentono di testare il comporta-
mento delle variabili, in particolare, si dovrebbe testare ogni formula con almeno
un test.
3.7.8 Simulazione
Una simulazione permette di calcolare tasse e benefici per il country-package
definito da entità, parametri, variabili e riforme avendo come base uno scenario
(che non è altro che un insieme di entità e variabili che generano la situazione che
vogliamo sfruttare).
N.B. Una simulazione funge anche da test per le riforme.
Questa rapida panoramica dei concetti principali ci consente di introdurre la visione
del sistema da un punto di vista più pratico: sappiamo ora cosa siano le Variabili, i
Parametri, le Entità e le Riforme, ma come vengono codificate?
3.8 Codifica del country-package: “Dalla legge al
codice”
In questa sezione viene illustrato come codificare i concetti chiave, descritti nella
sezione precedente.
3.8.1 Entità
Il processo di codifica di una nuova entità è molto complesso: sono necessarie
modifiche in vari file di configurazione e la riscrittura di parte del codice, espresso
nel core di openfisca, all’interno del proprio country-package.
Nella documentazione, infatti, non si fa alcun riferimento alla scrittura di una nuova
entità ma si parla solo di come utilizzarle e di come comporne di nuove partendo
da quelle esistenti.
Le operazioni principali utilizzabili su un’entità o un gruppo di entità sono l’ aggre-
gazione (che consente di aggregare valori definiti per ogni membro di un gruppo di
entità o di più entità singole) e la proiezione (che consente di conoscere il valore
di una certa variabile di un’entità).
3.8.2 Variabile
Come detto in precedenza, una variabile può assumere un valore calcolato tra-
mite una formula o assegnato input. La cosa interessante è che la prima opzione
comprende anche la seconda: se una variabile definisce una formula per essere cal-
colata, quest’ultima può assumere un valore sia calcolato tramite una formula sia
assegnato in input, mentre non è vero il contrario. Una variabile che può assumere
unicamente un valore tramite input, assume il seguente aspetto:
class variabile_di_esempio(Variable):
value_type = float
23

default_value = 100
entity = Person
label = u`Èsempo di variabile numerica''
definition_period = MONTH
Ogni variabile:
• Eredita della classe Variable definita all’interno del core di Openfisca;
• Ha un tipo di valore che può assumere, questi tipi però non sono dati dal
linguaggio Python, ma sono stati definiti dal team di Openfisca e sono i
seguenti:
– bool : boolean;
– date : date;
– Enum : valori discreti numerabili;
– float : float;
– int : integer;
– str : string.
• A seconda del tipo, assume un valore di default, che può essere però anche im-
postato dal programmatore (come nell’esempio). I valori di default, a seconda
del tipo della variabile, sono:
– bool : False;
– date : 1970-01-01;
– Enum : lista vuota;
– float : 0.0;
– int : 0;
– str : ’ ’ .
• Appartiene obbligatoriamente ad un’entità, in questo caso all’entità Persona;
• Può possedere una descrizione, indicata nel campo label;
• Può assumere diversi valori in base al periodo di definizione (nell’esempio, il
periodo è mensile). Il periodo di definizione è unico ed è scelto tra:
– MONTH : Il valore della variabile può cambiare di mese in mese (Es.
età di una persona);
– YEAR : Il valore della variabile può cambiare di anno in anno (Es.
IRPEF netta);
– ETERNITY : Il valore della variabile è una costante, ossia non può
cambiare nel tempo (Es. data di nascita).
24

Un fattore interessante è l’interoperabilità dei periodi: normalmente infatti
una variabile mensile non può essere calcolata su base annuale ed è vero anche
il contrario.
Esiste però un particolare attributo, denominato set input, che consente, a
seconda del valore assunto, di calcolare una variabile mensile su base annuale
e viceversa.
Una variabile che, invece, può essere calcolata tramite una formula assume la
seguente forma:
class variabile_di_esempio(Variable):
value_type = float
default_value = 100
entity = Person
label = u`Èsempo di variabile numerica calcolata
tramite formula''→
definition_period = MONTH
def formula(person,period,parameters):
return
person('altra_variabile_di_esempio',period)→
* parameters
.moltiplicatore_altra_variabile_di_esempio
Come detto in precedenza, una variabile calcolata tramite formula può anche assu-
mere un valore tramite input, tutto dipende da cosa forniamo al simulatore.
Se al simulatore imponiamo che la variabile di esempio sia uguale a un valore X
allora la variabile assumerà questo valore, se invece non è indicato alcun tipo di
valore, questo verrà calcolato tramite la sua formula.
Da ciò, si evince, che la regola di priorità per il simulatore sia:
V alore in input > valore calcolato tramite variabile
Questa regola, nata per facilitare il lavoro d testing, è in realtà uno svantaggio,
quantomeno a livello semantico. Il problema riscontrato è dettagliato nella Sezione
3.11.3).
La formula è una funzione che prende in input l’entità utilizzata nella formula per
effettuare il calcolo (nel nostro caso person), il periodo preso in considerazione per
il calcolo (che viene indicato in input al simulatore) e i parametri esistenti all’in-
terno del sistema. Il calcolo di una formula sfrutta da 0...n variabili di un entità e
da 0...n parametri esistenti.
Nell’esempio, la formula effettua una semplice moltiplicazione tra una variabile pro-
prietà dell’entità persona (per un certo periodo dato in input) e il suo parametro
moltiplicatore, dopodiché ritorna il risultato.
3.8.3 Parametro
Un parametro può essere codificato in diverse maniere, a seconda del suo scopo.
25

3.8.3.1 Parametro Base
Un parametro che ha come unico scopo, quello di rappresentare una semplice
proprietà numerica in base al periodo preso in esame, è il modello base. Vediamo
un esempio di parametro base :
description: Esempio di parametro base
unit: currency
values:
1993-01-01:
value: 1000
2010-01-01:
value: 1500
reference: https://openfisca.org/doc
/coding-the-legislation
/legislation_parameters.html
2020-01-01:
expected: 1700
Come si evince da queste righe di codice, un parametro base definisce dei valori a
seconda del periodo considerato, ma vediamo nel dettaglio da cosa un parametro di
questo genere è composto. Ogni parametro base ha:
• Una descrizione;
• Un riferimento legislativo (opzionale);
• Un’unità di misura. Possono essere di tre tipologie:
– years : il valore è rappresentato in anni;
– currency : il valore è rappresentato nella valuta corrente del paese;
– /1 : il valore è in percentuale (dove 1.0 = 100%).
• Dei valori per il parametro a seconda del periodo. I valori del parametro di
esempio vanno interpretati in questa maniera:
– Prima del 01-01-1993 questo parametro non esisteva;
– Dal 01-01-1993 al 01-01-2010 questo parametro assume valore 1000;
– Dal 01-01-2010 al 01-01-2020 questo parametro assume valore 1500;
– Ci si aspetta che dal 01-01-2020 questo parametro assuma come valore
1700. La parola chiave expected viene utilizzata per periodi successivi
a quello presente, è stato inserito per poter effettuare delle simulazioni
per gli anni futuri.
N.B. In questo caso, tutti i valori indicati sono dei valori interi. Bisogna stare
attenti ad utilizzarli, in quanto potrebbero portare ad errori nel calcolo delle
varie formule (Problema del troncamento della divisione intera [19]).
Per evitare ogni sorta di problema è consigliabile indicare il valore, anche se
non ha cifre dopo la virgola, come numero reale (invece di 1000 scrivere
1000.00).
26

3.8.3.2 Parametro a scala
Una scala è formata da raggruppamenti di valori, tassi e soglie. Un para-
metro a scala viene di solito definito per gestire calcoli basati su scaglioni (Es.
calcolo dell’IRPEF lorda).
Prendiamo come esempio di parametro a scala un frammento di codice del file
’Aliquote IRPEF’ da noi codifcato:
description: Aliquote dell'imposta sul reddito delle
persone fisiche→
reference: https://goo.gl/bd4986
brackets:
- rate:
2007-01-01:
value: 0.23
threshold:
2007-01-01:
value: 0.0
- rate:
2007-01-01:
value: 0.27
threshold:
2007-01-01:
value: 15000
Ogni parametro a scala possiede:
• Una descrizione;
• Un riferimento legislativo (opzionale);
• 1..n Tassi. Ogni tasso è formato a sua volta da:
– Valori per diversi periodi (anche se nell’esempio è definito un solo valore
a partire dal 01-01-2007);
– Soglie per diversi periodi (anche se nell’esempio è definito un solo valore
a partire dal 01-01-2007).
La prima domande che ci si pongono, dato che questo è un parametro più complesso
rispetto a quello di base, è come vada interpretato e come poterlo utilizzare. Per
poter rispondere a queste domande bisogna introdurre la funzione calc(). Prendia-
mo come esempio la seguente istruzione, utilizzata per calcolare la quota di IRPEF
lorda all’interno del nostro progetto:
parameters(period).
aliquote_scaglioni_IRPEF.calc(reddito_imponibile)
27

Questa istruzione è suddivisa in 3 sezioni:
• parameters(period).aliquote_scaglioni_IRPEF
# richiamo il parametro a scala
• reddito_imponibile
# valore che verrà passato alla funzione calc()
• calc(reddito_imponibile)
# calcola il valore della scala
# in base all'oggetto passato in input
Nel nostro caso, la funzione calc() prende in input il valore reddito imponibile e
si applica sul parametro a scala aliquote scaglioni IRPEF.
Per capire cosa fa la funzione calc() supponiamo che il valore di
reddito imponibile sia 20000. La funzione applicata a questa cifra effettua il
seguento calcolo:
(15000 ∗ 0.23) + ((20000 − 15000) ∗ 0.27)
Il calcolo scaturisce dal fatto che, prima di ogni cosa, la funzione calc() controlla
in quale range di soglia si trovi il valore passato in input utilizzando come metro di
giudizio il campo threshold. Nel nostro caso il valore è maggiore della soglia dei
15000 per la quale vale la rata del 27 %. Questo non significa che tutto il valore
passato sia la base per il calcolo del 27 %, infatti, questa funzione, accoppiata con
il parametro a scala, serve per effettuare calcoli a scaglioni, ed è per questo che,
prima si calcola il 23 % di 15000 (che è il massimo del primo range di valori) e poi
si calcola il 27 % ma solo della differenza tra il valore passato in input e la soglia
minima del range in cui ci si trova.
Come esempio rafforzativo, prendiamo il caso in cui il reddito imponibile sia
13000, il calcolo effettuato sarebbe il seguente:
((13000 − 0) ∗ 0.23)
Da questi esempi è chiaro anche come il parametro a scala debba essere in-
terpretato: nell’esempio il parametro assume il valore di 0.23 se la cifra passata in
input è maggiore di 0 e minore di 15000, altrimenti assume 0.27.
In questa maniera, si possono creare n scaglioni e, a seconda delle esigenze, applicare
la funzione calc() per effettuare il calcolo, in maniera semanticamente corretta.
3.8.3.3 Parametro Fancy Indexing
L’ultimo tipo di parametro è il parametro fancy indexing, ossia un parametro
che viene calcolato in base al valore di una certa Variabile. Questo tipo di oggetto è
molto comodo in situazioni in cui esistono delle condizioni sul valore di una variabile
generica: Il parametro è infatti, indicizzato di fantasia, nel senso che non si basa su
un valore di una variabile specifica ma su un valore generico che qualsiasi variabile
può assumere. Vediamo il seguente esempio:
28

zona_1:
single:
description: "Ammontare beneficio per una certa
persona single nella zona 1"→
values:
2015-01-01:
value: 150
coppia:
coppia nella zona 1"→
values:
2015-01-01:
value: 250
zona_2:
single:
description: ""Ammontare beneficio per una certa
persona single nella zona 2"→
values:
2015-01-01:
value: 200
coppia:
coppia nella zona 2"→
values:
2015-01-01:
value: 300
Il funzionamento è il seguente: I valori zona 1 e zona 2 sono valori che posso essere
assunti da una qualsiasi variabile (che è sicuramente un Enum in questo caso)
e per ognuno di essi vengono definiti ben due parametri utilizzabili (single e
coppia). Sarà cura del programmatore, scegliere quale di questi utilizzare in base
alle esigenze, un esempio di utilizzo è il seguente:
def formula(famiglia, period, parameters):
coppia = famiglia('coppia', period)
zona = famiglia('zona_abitazione', period) #
zona_abitazione può essere solamente zona_1 o
zona_2
→
→
P = parameters(period).beneficio_abitazione[zona]
return where(coppia, P.coppia, P.single) # ritorno il
parametro coppia se la famiglia è formata da due
persone, altrimenti quello per single
→
→
29

3.8.4 Riforma
Una riforma, è un insieme di modifiche che possono essere applicate ad un
sistema di tasse e benefici. Viene solitamente utilizzata per valutare l’impatto di un
possibile cambiamento nel sistema legislativo.
Il cambio al sistema apportato da una Riforma può concretizzarsi in tre modi:
• Ridefinire la formula per il calcolo di una variabile esistente;
• Ridefinire un parametro esistente;
• Introdurre un nuovo parametro (staticamente o dinamicamente).
3.8.4.1 Ridefinire la formula per il calcolo di una variabile esistente
Grazie ad una riforma è possibile misurare l’impatto della ridefinizione del calcolo
di una variabile. Questo strumento è molto comodo in quanto, il cambiamento del
calcolo di una variabile (in particolare una tassa) potrebbe impattare in maniera
inaspettata sull’intero sistema. La ridefinizione di una variabile è molto semplice:
basta riscrivere la stessa variabile (cambiandone la struttura) e poi far partire una
simulazione per constatare l’impatto del cambiamento.
Prendiamo come esempio una semplice variabile del sistema attuale:
class variabile_di_esempio_senza_riforma(Variable):
value_type = float
entity = Person
label = u`Èsempo di variabile da riformare"
definition_period = YEAR
return
* parameters
Supponiamo ora di voler riformare questa variabile e di cambiare il corpo della sua
formula scrivendo la seguente variabile riformata:
class variabile_di_esempio_riformata(Variable):
value_type = float
entity = Person
label =
u``Variabile riformata da applicare su
variabile_di_esempio_senza_riforma"→
definition_period = YEAR
return
30

* (1.0 - parameters
.moltiplicatore_altra_variabile_di_esempio)
Supponendo che il parametro moltiplicatore altra variabile di esempio sia una
percentuale, decido di cambiare la moltiplicazione e di trasformare la formula della
variabile da:
return person('altra_variabile_di_esempio',period)
* parameters
a
return person('altra_variabile_di_esempio',period)
* ( 1.0 - parameters
.moltiplicatore_altra_variabile_di_esempio)
Una volta definita, la variabile riformata va applicata al sistema. E’ ora di scrivere
una riforma! Prendiamo come esempio, la seguente riforma:
class simple_reform(Reform):
name = u'Reform on
variabile_di_esempio_senza_riforma'→
def apply(self):
self.update_variable(
variabile_di_esempio_senza_riforma)
Ogni riforma:
• Eredita dalla classe Reform definita nel core;
• Possiede un nome;
• Deve sempre definire il metodo apply, sia che essa debba essere applicata su
una variabile che su un parametro.
In questo caso il metodo apply, richiama la funzione update variable definita
all’interno del core nella classe Reform. Questo metodo farà in modo di aggiornare
la variabile in una simulazione.
Da notare che la la riforma e la variabile riformata dovrebbero trovarsi nello
stesso file, sia per motivi di namespace sia per ragioni convenzionali.
31

3.8.4.2 Ridefinire un parametro esistente
Il procedimento è molto simile a quello della variabile ma con qualche cam-
biamento strutturale. Innanzitutto per ridefinire un parametro esistente bisogna
definire una funzione di modifica dei parametri come nel seguente esempio:
def modify_parameters(parameters):
reform_period = periods.period("2015")
parameters.tax_on_salary.brackets[1].threshold.
update(period = reform_period, value = 4000)
return parameters
In questo caso la modifica si applica per l’anno 2015, su un parametro a scala,
nella seconda sezione del raggruppamento (brackets[1]), aggiornando la soglia per
la quale varrà la rata in quella sezione con il valore 4000. Dopodichè, si scrive
una riforma che sfrutta il metodo modify parameters per effettuare le stesse
operazioni espresse nella sezione precedente ma prendendo di mira un parametro al
posto di una variabile. La riforma per modificare un parametro esistente avrà un
aspetto di questo tipo:
class incrementare_soglia_minima(Reform):
name = u'Incrementare la soglia minima'
def apply(self):
self.modify_parameters(modifier_function =
modify_parameters)→
3.8.4.3 Introdurre un nuovo parametro
Come detto in precedenza, grazie ad una riforma è possibile non solo modificare
un parametro ma anche introdurne uno nuovo in maniera statica o dinamica.
Per introdurre un nuovo parametro in maniera statica, bisogna innanzitutto posse-
dere un file in cui è definito un parametro ma che non si trova nel percorso dei
parametri (per questo si dice in maniera “statica”, in quanto il file esiste già ed il
parametro è già fissato).
Dopodiché, bisogna scrivere la solita funzione modify parameters che, questa vol-
ta, ha lo scopo di caricare in memoria il file. Un esempio di codice generico è il
seguente:
import osˆÂ
from openfisca_core.parameters import
load_parameter_file→
dir_path = os.path.dirname(__file__)
file_path = os.path.join(dir_path, 'new_parmt.yaml')
32

reform_parameters_subtree =
load_parameter_file(file_path, name='new_parmt')→
parameters.add_child('new_parmt',
reform_parameters_subtree)→
return parameters
Una volta definita questa funzione, si scrive una riforma applicando il metodo
modify parameters:
class some_reform(Reform):
def apply(self):
self.modify_parameters(modifier_function =
modify_parameters)→
Per introdurre invece un nuovo parametro in maniera dinamica, si eseguono gli
stessi passi ma cambiando la funzione di modify parameters che ora, invece di
caricare un file in cui si trova il parametro, ne definisce direttamente uno.
L’esempio di codice generico per questa situazione è il seguente:
from openfisca_core.parameters import Parameter
reform_parameters_subtree = Parameter('new_parmt',
data = {→
'description': 'New dinamyc parameter'
'values': {
"2000-01-01": {'value': 550, reference =
'http://openfisca.readthedocs.io→
/en/latest/parameters.html'},
"2017-01-01": {'value': 600, reference =
'http://openfisca.readthedocs.io→
/en/latest/parameters.html'}
}
})
parameters.add_child('new_parmt',
reform_parameters_subtree)→
3.8.5 Test per le variabili
I test riguardanti le variabili, vengono eseguiti in un ambiente virtuale di Pew.
L’unico scopo di questi test è controllare se gli effetti del calcolo di una variabile
siano quelli voluti. Prendiamo come esempio il seguente test:
- name: Test esempio
period: 2018
33

input_variables:
reddito_complessivo: 10000
oneri_deducibili: 1000
output_variables:
irpef_lorda: 2070
Come si evince dal codice, ogni test possiede:
• Un nome;
• Un periodo sul quale le variabili vengono calcolate;
• Un insieme di variabili di input;
• Un insieme di variabili di output attese.
I test si comportano in una maniera molto pervasiva: un qualsiasi test, fa in modo
di calcolare, non solo le variabili attese in output, ma anche tutte le altre variabili
esistenti.
In realtà, la maggior parte della variabili assumerà il valore di default, a meno che
la formula per il calcolo delle stesse non contenga le variabili date in input, in quel
caso assumeranno un valore diverso.
Se il test fallisce, significa che le variabili calcolate in output assumono dei valo-
ri diversi rispetto a quello specificato nei test, o che c’è stato un qualche errore
sintattico.
3.8.6 Simulazione
Le simulazioni possono essere eseguite su un sistema di tasse benefici standard
o riformato.
Supponendo di voler calcolare una variabile del sistema standard il procedimento
è il seguente:
from openfisca_italy import CountryTaxBenefitSystem #
import tax benefit system→
from openfisca_italy.scenarios import Scenario # import
scenario→
# definire funzione per inizializzare scenario
def init_profile(scenario):
scenario.init_single_entity(
period = '2017',
person = dict(
age = 50
var_reddito= 10000,
# ...
)
)
return scenario
34

#carico il sistema di tasse e benefici
tax_benefit_system = CountryTaxBenefitSystem()
#creo uno scenario sul sistema
scenario = tax_benefit_system.new_scenario()
#inizializzo lo scenario
scenario = init_profile(simple_scenario)
# creo una simulazione su uno scenario
simulation = scenario.new_simulation()
# calcolo una variabile sulla simulazione
simulation.calculate('irpef_lorda','2017')
Se invece vogliamo calcolare una variabile del sistema riformato si utilizza lo
stesso codice di prima, solamente cambiando il sistema di tasse e benefici preso in
esame:
# prendo sistema con riforma applicata
sistema_con_riforma =
diminuzione_aliquota_IRPEF_redditi_inferiori_15000(→
tax_benefit_system)
# creo un nuovo scenario sul sistema con riforma
reform_scenario = sistema_con_riforma.new_scenario()
# inizializzo lo scenario sul sistema con riforma
reform_scenario = init_profile(reform_scenario)
# creo una simulazione sullo scenario
simulation_riforma = reform_scenario.new_simulation()
# calcolo la variabile sulla simulazione del sistema
riformato→
simulation_riforma.calculate('irpef_lorda','2017')
3.8.7 Estensione dei file per la codifica
Quello che non è stato detto, è quale sia l’estensione dei file supportata dai vari
concetti dell’ecosistema Openfisca.
Concetto Tipologia FIle
Entità ’.py’
Variabili ’.py’
Parametri ’.yaml’
Simulazioni ’.py’
Situation ’.json’
Test Variabili ’.yaml’
Test Riforme ’.py’
Tab. 3.1: Tipologie di file associate a concetti
35

3.9 Flusso operativo della simulazione
Dopo aver descritto tutte le componenti, utili al fine di definire un sistema di
tasse e benefici tramite lo stack di moduli openfisca, è doveroso specificare come
questi elementi si concatenino per effettuare una semplice simulazione.
Segue un diagramma di flusso, che verrà dettagliato effettuando dei focus nelle sue
varie regioni:
Fig. 3.4: Flusso di lavoro di una simulazione Openfisca
36

3.9.1 Regione1
Fig. 3.5: Flusso di lavoro di una simulazione Openfisca: Regione 1
La prima cosa da fare per effettuare una simulazione è definire, all’interno di un
file del country-package (script python), l’l’ambiente della simulazione.
Per definire questo ambiente, è necessario generare il sistema completo di tasse e
benefici (operazione standard della componente openfisca-core) ed inizializzare
una situazione fiscale.
3.9.2 Regione2
Per inizializzare una situazione fiscale è necessario selezionare:
• N coppie di <Variabile di input-Valore assegnato alla variabile>;
• N <Variabile di output>;
Tutte le variabili selezionate, vengono impacchettate in una Situazione fiscale,
che accoppiata con il sistema di tasse e benefici, è in grado di generare una
situazione fiscale compatibile con il simulatore openfisca.
37

3.9.3 Regione3
Una volta generata una situazione fiscale compatibile con il simulatore open-
fisca si effettua la simulazione.
Basandosi sulle N coppie di <Variabile di input-Valore assegnato alla varia-
bile> indicate nella situazione fiscale, il simulatore calcola le N <Variabile di
output> e tutte le variabili necessarie al fine di calcolare quest’ultime.
Una volta effettuati i calcoli, il simulatore restituisce i vari risultati al country-
package che ha la possibilità di mostrarli a video o utilizzarli per effettuare altre
simulazioni.
38

3.10 Openfisca country-template
3.10.1 Country-template
Per inizializzare il repository di una de-
terminata nazione bisogna seguire un deter-
minato numero di step. La prima co-
sa da fare è clonare o scaricare, il pro-
getto openfisca-country-template (fruibi-
lie al seguente link https://github.com/
openfisca/country-template/).
Successivamente, basta far eseguire una serie di
istruzioni, codificate in Bash scripting, sul pro-
prio elaboratore per adattare il progetto e creare
cos`ı una base del sistema fiscale del paese di ri-
ferimento (generando l’albero di directory
che troviamo in figura).
Nonostante la facilità con cui sia possibile model-
lare una base per un sistema fiscale, c’è un grosso
limite: come specificato, le istruzioni sono codifi-
cate in Bash scripting, ciò significa che queste
funzionano unicamente su sistemi operativi Unix
(OSx, Ubuntu etc...), per questo, abbiamo deciso
di contribuire sviluppando uno script python
cross-platform che emulasse i comportamenti de-
scritti dal team (sezione 3.11).
Openfisca-country-template non è altro che
un insieme di file e cartelle necessarie per iniziare
a sviluppare il sistema fiscale per il proprio pae-
se, infatti, esso contiene vari file che sono generali
per ogni sistema fiscale, tra i quali troviamo:
• File di configurazione ed informazione che
agevolano il lavoro dello sviluppatore;
• Cartelle .github e .circleci;
• Cartella openfisca-name of country, che
contiene, non solo la struttura base di un
sistema fiscale, ma anche vari file che fungono da esempio per comprendere il
collegamento tra le varie componenti viste nella sezione 3.7.
39

3.11 Contributo al progetto Openfisca
In questa sezione, verranno discussi i vari contributi forniti ai vari progetti della
community Openfisca, escludendo openfisca-italy al quale dedicheremo un capitolo
intero.
3.11.1 Contributo al country-template
Per contribuire ad openfisca-country-template abbiamo deciso di sviluppare
due python script:
• Lo script per inizializzare il country-template di un qualsiasi paese
(disponibile al link: https://pastebin.com/fHXRUvac), che generaliz-
za la procedura di adattamento del country-template, rendendola cross-
platform ed user-friendly.
• Lo script per eseguire ricorsivamente tutti i test esistenti in una di-
rectory scelta dall’utente (disponibile al link: https://pastebin.com/
j8BPT3dm), che consente con due semplici click, di eseguire tutti i test all’in-
terno di un sistema fiscale, senza dover ricorrere all’uso del terminale.
3.11.2 Contributo alla documentazione
Durante lo studio della documentazioe e lo sviluppo del software, ci siamo ac-
corti che alcune istruzioni erano errate o mancanti. Parlando col team di sviluppo,
abbiamo potuto aggiornare la documentazione esistente per renderla corretta.
In particolare abbiamo:
• Aggiornato la documentazione riguardante un’istruzione errata e un’istru-
zione mancante nella sezione della codifica delle riforme;
• Preparato l’introduzione di documentazione mancante, riguardante
l’importazione di particolari variabili (Enum) da un file all’altro (che è as-
solutamente necessaria per avere una buona organizzazione del codice). Di
seguito la bozza da migliorare e convertire in markdown:
Per poter importare una variabile di tipo Enum, da
un file all'altro è necessario che questo
particolare tipo di variabile si trovi su un
file '.py' in un livello di gerarchia più alto
rispetto al file in cui lo si vuole importare.
Normalmente questa azione non serve, in quanto
tutti gli altri tipo di variabili esistono a
livello globale, a prescindere dalla gerarchia
di directory in cui queste si trovano.
→
→
→
→
→
→
→
→
40

3.11.3 Contributo al core di OpenFisca
Sviluppando il sistema fiscale italiano, ci siamo accorti di alcune migliorie che
potevano essere apportate ad openfisca-core per rendere migliore lo sviluppo di un
generico country-package. In particolare, abbiamo suggerito due migliorie, una di
queste segnalata formlamente tramite issue (visionabile al seguente link: https:
//github.com/openfisca/openfisca-core/issues/657). Questi sugge-
rimenti sono stati accettati dagli sviluppatori e consistono in:
• Nuova funzionalità interpretativa del Fancy Indexing Brevemente, il
Fancy Indexing è un meccanismo che consente di calcolare il valore dei
parametri in base al valore delle variabili a run-time.
Per questo meccanismo, gli sviluppatori hanno previsto solamente un calcolo
di uguaglianza:
– Se la variabile a assume il valore X1 allora il param calc su a varrà Y1;
– Se la variabile a assume il valore X2 allora il param calc su a varrà Y2;
– ...
– Se la variabile a assume il valore Xn allora il param calc su a varrà Yn;
Durante lo sviluppo delle varie leggi, abbiamo trovato l’esigenza di calcolare
parametri in base a un range di valori matematici:
Ad esempio, ci sono alcune soglie che, se non superate, rendono i redditi
scaturiti da pensioni non sono soggetti all’imposta IRPEF. Queste soglie,
cambiano in base all’età della persona: Se il soggetto ha 75 anni o meno, vale
il valore di soglia X1 mentre se ha più di 75 anni entra in gioco il valore di
soglia X2.
Per implementare un concetto del gener, con il meccanismo attuale dell’ugua-
glianza, avremmo dovuto definire il primo valore per 75 volte e il secondo per
almeno altre 40 (supponendo che una persona possa vivere fino a 115 anni)
con conseguente spreco di codice.
La soluzione al problema, da noi proposta, è quella di introdurre un simbolo
che consenta al simulatore, di capire che non vogliamo confrontare il valo-
re della variabile tramite uguaglianza ma tramite un altro criterio (come ad
esempio >= ,<= ,> ,< ...).
• Due campi aggiuntivi per le Variabili
L’esigenza della richiesta dell’introduzione di due nuovi campi, è sorta durante
lo sviluppo di variabili numeriche che non vengono calcolate tramite una
formula; infatti, l’introduzione di questi due campi varrebbe solamente per
variabili numeriche (una situazione simile alle variabili Enum, che necessitano
di un campo aggiuntivo rispetto a tutti gli altri tipi).
Nel sistema legislativo italiano, ed anche in molti altri sistemi legislativi, esi-
stono variabili che non dipendono da nessun’altra variabile o parametro, ma
che sono soggette a imposizioni numeriche (ad esempio, ci sono alcune detra-
zioni IRPEF che non possono superare una certa quantità fissata X).
Queste variabili vengono ovviamente tradotte in variabili il cui valore è
assegnabile unicamente tramite input, ed è proprio qui che si presenta
quello che abbiamo denominato Problema del limite superiore-inferiore:
41

Una variabile, il cui valore può essere assegnato unicamente in input, non viene
sottoposta ad alcun controllo semantico, ciò significa che il valore teorico di
una variabile, che non dovrebbe superare/precedere un certo valore numeri-
co X, può tranquillamente farlo.
Si potrebbe pensare, che questo problema non valga per le variabili il cui
valore è assegnabile tramite formula, in quanto la formula impone , chia-
ramente, un controllo semantico.
Il problema è purtroppo valido, anche per loro: come descritto nella sezio-
ne 3.8.2, relativa alle variabili “se una variabile definisce una formula
per essere calcolata, quest’ultima può assumere un valore sia calcolato tramite
una formula sia assegnato in input, mentre non è vero il contrario”, ma per
l’assioma che regola le priorità dell’assegnamento: l’assegnamento in in-
put è più forte dell’assegnamento tramite formula.
Ciò significa, che anche il controllo semantico dettato dalla formula può essere
facilmente ignorato. La soluzione da noi proposta, consiste nell’introdurre due
campi all’interno della dichiarazione della variabile numerica:
– max limit: Per definire quale sia il valore massimo che la variabile
numerica può assumere;
– min limit: Per definire quale sia il valore minimo che la variabile nume-
rica può assumere;
Dialogando con il team, abbiamo trovato una soluzione provvisoria che evita
il problema, ma non lo risolve.
La soluzione, consiste nel duplicare la variabile, facendo in modo che la prima
copia, sia quella assegnabile e la seconda sia quella che il sistema considererà
per i suoi calcoli e che sottopone la prima ai controlli semantici, una sorta di
wrapping tra variabili.
Ci si chiede ora il motivo per il quale questa soluzione evita il problema ma
non lo risolve: la seconda variabile (ossia quella che sottopone al controllo
la prima, e che verrà considerata dal sistema) può comunque essere assegnata
in input, cadendo cos`ı nel problema del limite superiore-inferiore.
42

4. OpenFisca Italy
In questa sezione, discuteremo dei criteri con i quali abbiamo scelto le leggi del
sistema fiscale italiano da introdurre nel sistema openfisca-italy e di come queste
sono state implementate.
4.1 Scelta della legislazione
Nella fase di studio preliminare, ci siamo chiesti quali potessero essere le Fonti
Normative principali da dover sviluppare e inserire con priorità, all’intero del sistema
Openfisca italiano.
Ragionando assieme all’ Avv. Lonoce Antonino abbiamo concordato che le prime
Fonti da inserire nel sistema dovessero essere:
• Utilizzate dalla maggior parte delle persone fisiche (dato che per ora, nel
sistema openfisca-core non è possibile definire variabili per entità giuridiche);
• Più o meno stabili a livello di comportamento.
Basandoci su questi criteri, la scelta è ricaduta nell’ambito delle Imposte, in parti-
colare sull’ Imposta sul reddito delle persone fisiche (IRPEF) e sull’ Imposta
municipale unica (IMU).
Queste imposte sono state scelte per due motivazioni principali:
• Ricomprendono la maggior parte dei soggetti (tutti i cittadini sono
contribuenti in tema dell’Imposta sul Reddito a meno di esenzioni, e molti
sono soggetti ad Imu);
• Sono utili per effettuare delle simulazioni e delle statistiche comples-
se. Immaginiamo, ad esempio, di poter calcolare l’imposta Irpef dovuta da
100000 cittadini, ognuno con redditi e situazioni fiscali autonome, prima con la
normative in vigore e poi applicando una “riforma” definita dal legislatore.
Le informazioni scaturite da questi calcoli complessi, una volta organizzate,
potrebbero facilmente aiutare il legislatore nel validare se si debba/possa av-
viare un procedimento legislativo (Es. abbassare o alzare un’aliquota, per un
determinato range di redditi).
43

4.2 Nozioni teoriche IRPEF
In questa sezione, discuteremo della complessa struttura che porta alla defini-
zione dell’IRPEF. Tutte le informazioni relative a quest’imposta sono state derivate
dal TUIR [20] e dal sito dell’Agenzia Delle Entrate [21].
4.2.1 Definizione legislativa
L’Imposta sul reddito delle persone fisiche è l’imposta diretta sul reddito che
colpisce le persone fisiche nell’ordinamento tributario nazionale.
L’imposta colpisce la capacità contributiva personale globale del contribuente (red-
dito posseduto, situazione personale e situazione familiare) con un approccio pro-
gressivo, ossia, viene utilizzata un’aliquota più elevata all’aumentare del reddito
totale [22]. La tabella del sistema a scaglioni [23], che indica le aliquote e la quota
lorda da pagare in base al reddito, è la seguente:
4.2.2 Struttura generale
Per poter calcolare, in maniera corretta, l’ imposta sul reddito delle persone fisi-
che è necessario compilare vari fascicoli [24], in particolare, è necessario il fascicolo
1:
Questo fascicolo è composto da quadri di vario tipo, in particolare, ogni quadro
possiede un insieme di righi, per il quale è prevista una regolamentazione per la
compilazione.
La compilazione dei quadri RA, RB, RC, CR, RP LC sono necessari alla for-
mazione della base imponibile e quindi, alla compilazione del quadro RN relativo
alla determinazione dell’IRPEF e di tutti i quadri successivi (RV, DI, RX).
Sarebbe tedioso e superfluo, descrivere tutti i quadri uno per uno, inoltre, tutte
44

le istruzioni per la compilazione sono presenti nel sito dell’Agenzia Delle Entra-
te (https://goo.gl/BNxNWQ). La descrizione dei quadri verrà, quindi, limitata
alle nozioni necessarie per il calcolo dell’imposta in esame. Di seguito il quadro RN,
relativo alla determinazione dell’IRPEF:
4.2.2.1 Base imponibile
Il presupposto d’imposta e la base imponibile sono individuati nell’ambito delle
discipline delle singole categorie reddituali.
La base imponibile è la cifra sulla quale viene calcolata l’imposta lorda IRPEF, ed
è generata dal seguente calcolo:
Base imponibile (RN4)= Reddito complessivo
- Deduzione per abitazione principale
- Oneri deducibili
4.2.2.2 Reddito complessivo
Il reddito complessivo(RN1) è il risultato della sommatoria delle redditività
prodotte dalla persona fisica. Le tipologie di reddito, che concorrono alla formazione
del reddito complessivo, restrittivamente sono:
• Redditi di lavoro dipendente, sono quelli che derivano da rapporti aventi
per oggetto la prestazione di lavoro, con qualsiasi qualifica, alle dipendenze e
sotto la direzione di altri, compreso il lavoro a domicilio quando è considerato
lavoro dipendente secondo le norme della legislazione sul lavoro [25];
45

• Redditi di lavoro autonomo,sono quelli derivanti dall’esercizio abituale,
ancorché non esclusivo, di attività lavorative diverse da quelle di impresa o di
lavoro dipendente [26];
• Redditi fondiari, sono quelli inerenti ai terreni e ai fabbricati, situati nel
territorio dello Stato, che sono o devono essere iscritti, con attribuzione di
rendita, nel catasto dei terreni o nel catasto edilizio urbano [27];
• Redditi di capitale, sono redditi derivanti dalle rendite finanziarie e dai
dividendi da partecipazione [28];
• Redditi di impresa, sono redditi derivanti dall’esercizio di imprese commer-
ciali, ossia dall’esercizio professionale ed abituale, anche se non esclusivo, delle
attività indicate nell’art. 2195 del codice civile e delle attività agricole indicate
nell’art. 32, c.2, lettere b) e c), che eccedono i limiti ivi stabili, anche se non
organizzate in forma di impresa. [29];
• Redditi diversi, costituiscono una categoria di reddito residuale, che ha
carattere eterogeneo, in quanto comprende i redditi più disparati che non
rientrano nelle altre categorie di reddito o che hanno caratteri peculiari non
inquadrabili in una categoria tipica [30].
In termini algoritmici, il reddito complessivo è dato da:
Tipologie reddito = [redditi lavoro dipendente,
redditi di capitale, redditi lavoro autonomo,redditi fondiari,
redditi di impresa, redditi lavoro dipendente]
Reddito complessivo =
N
t=1
Tipologie reddito[t]
Gli importi delle varie categorie reddituali, vengono definiti compilando i vari quadri
RA,RB ed RC elencati di seguito:
(a) Quadro RA (b) Quadro RB (c) Quadro RC
4.2.2.3 Deduzione per abitazione principale
Prima di mostrare come si determina la deduzione per abitazione principale,
bisogna definire cosa sia l’ abitazione principale:
“Per abitazione principale si deve intendere l’immobile che il contribuente possiede
46

a titolo di propriet`a o di altro diritto reale e che ha destinato a dimora abituale
propria e dei propri familiari” [31].
Questa deduzione compete:
• al proprietario;
• all’ usufruttuario;
• al titolare di un diritto di abitazione;
• ai familiari del contribuente, se parenti entro il terzo grado ed aﬃni entro il
secondo.
La deduzione per abitazione principale(RN2), si calcola sottraendo al reddito
complessivo il reddito dell’abitazione principale e delle relative pertinen-
ze, attribuita alla casa di abitazione e riducendo, in tal modo, l’importo sul quale
calcolare le imposte.
4.2.2.4 Oneri deducibili
Il totale degli oneri deducibili(RN3), scaturisce dalla compilazione della Se-
zione II del quadro RP, indicato di seguito: Le istruzioni per la compilazione,
sono rimandate alla sezione relativa nel sito della Agenzia Delle Entrate.
47

4.2.2.5 Imposta lorda
Per determinare l’imposta lorda IRPEF(RN5) applicare il metodo a sca-
glioni alla base imponibile. Il calcolo a livello algoritmico `e il seguente:
Imposta lorda IRPEF(R) =
N
i=1
αi ∗ max(0, min(R, Si+1) − Si)
R: Reddito
si: Scaglione
αi: Aliquota
sn+1: ∞
n: numero scagloni
Supponendo che valga la seguente tabella
i
Si
Scaglione
αi
Aliquota
1 0 23%
2 15000 27%
3 28000 38%
4 55000 41%
n = 5 75000 43%
4.2.2.6 Imposta netta
Per calcolare l’imposta IRPEF netta(RN26) `e necessario sottrarre dall’impor-
to lordo il totale delle altre detrazioni d’imposta e crediti d’imposta(RN22)
e il totale delle detrazioni d’imposta(RN25):
Imposta netta IRPEF(R) = Imposta lorda IRPEF(R) -
totale altre detrazioni imposta crediti imposta - totale detrazioni imposta
4.2.2.7 Totale detrazioni d’ imposta
Il totale delle detrazioni di imposta si ottiene sommando il totale delle detra-
zioni per carichi di famiglia e lavoro (RN8) e dalle altre detrazioni indicate
dal rigo RN12 al RN21.
4.2.2.8 Totale altre detrazioni d’ imposta e crediti d’imposta
Il totale delle altre detrazioni di imposta si ottiene dalla somma delle detrazioni
per spese sanitarie per determinate patologie(RN23) e dal totale dei crediti
d’imposta che generano residui(RN24).
48

4.3 Implementazione IRPEF
Dopo aver discusso con l’Avv. Lonoce Antonino dell’imposta ed aver appreso
tutte le nozioni necessarie, siamo passati alla codifica 1
.
Per aiutare un futuro programmatore nella lettura del codice, l’albero di directory
generato per l’implementazione, ha seguito fedelmente la struttura della dichia-
razione dei redditi[32]. Le variabili e i parametri, presenti all’interno dei vari file,
sono stati definiti seguendo le istruzioni per la compilazione delle dichiara-
zione dei redditi [33].
L’implementazione dei vari quadri dell’IRPEF è stata molto lunga data la comples-
sità degli aspetti da gestire (detrazioni specifiche, calcoli di aliquote...). Nonostante
il lungo lavoro di codifica, non è stato possibile implementare in maniera completa
la compilazione di tutti i quadri necessari. In particolare, è possibile compilare:
• Il Quadro RP, destinato all’indicazione di specifici oneri che, a seconda dei
casi, possono essere fatti valere nella dichiarazione dei redditi come detraibili
e deducibili.
• Il Quadro LC, destinato all’indicazione della Cedolare secca sulle locazioni.
In particolare, il Quadro LC accoglie la liquidazione unitaria della cedolare
secca complessivamente dovuta dal contribuente per il periodo dichiarativo.
• Il Quadro RN, che riassume tutti i dati, dichiarati negli altri quadri di
questo modello, utili per determinare l’imposta sul reddito delle persone fi-
siche (Irpef). Questo quadro è compilabile fino al rigo RN26 che corrisponde
all’importo dell’IRPEF netta.
Tutte le varie implementazioni, consentono di definire e/o calcolare ogni rigo per
tutti i quadri2
.
La struttura di tutti gli altri quadri è stata creata ma non implementata. L’imple-
mentazione dell’IRPEF è disponibile al seguente link: https://github.com/openfisca/openfisca-
italy3
.
1
Prima di gettarci a capofitto nell’implementazione dell’IRPEF, abbiamo definito variabili e
parametri generali per ogni persona fisica, come l’età anagrafica, il codice fiscale, etc...
2
Alcuni righi dei vari quadri (in particolare le detrazioni per i figli a carico) non sono state
sviluppate completamente a causa di strutture dati mancanti che sono ancora in fase di sviluppo
nella piattaforma OpenFisca
3
Tuttavia le varie implementazioni si trovano in branch differenti rispetto a quello principale.
49

4.4 Nozioni teoriche IMU
4.4.1 Definizione legislativa
L’Imposta municipale unica[34] è un’imposta italiana che si applica sugli immo-
bili che sostituisce l’ICI. Questa imposta[35] è:
• Diretta: colpisce direttamente il patrimonio che una persona possiede in un
dato momento;
• Patrimoniale: colpisce la disponibilità di ricchezza accumulata anche nell’ar-
co di intere generazioni.
Dal 2014 è stata integrata nella IUC (Imposta Unica Comunale)[36], imposta che
raggruppa le principali imposte locali presenti nel Ordinamento italiano:
• IMU;
• TASI;
• TARI.
4.4.2 Struttura generale
4.4.2.1 Soggetti coinvolti
Nell’imposta sono coinvolti due tipologie di soggetti[37]:
• Soggetto Attivo: Il Comune (che ha funzione impositiva);
• Soggetti Passivi, categoria che include:
– Il proprietario di un immobile;
– I titolari di usufrutto, uso, enfiteusi, abitazione e superficie;
– L’ex coniuge titolare di un immobile;
– Il locatario di un immobile (ad esempio: l’immobile sia concesso in lea-
sing);
– Il concessionario di aree demaniali (ad esempio uno stabilimento balnea-
re).
50

4.4.2.2 Immobili
Il legislatore ha diviso gli immobili nelle seguenti categorie[38] per strutturare al
meglio il calcolo dell’imposta:
Fig. 4.2: Categorie Catastali.
4.4.2.3 Rendita catastale
Per calcolare l’IMU è necessario conoscere la rendita catastale[39] di un bene
immobile che viene calcolata in base alla categoria di appartenenza, per esempio la
categoria B viene calcolata in base ai metri cubi. Il valore della rendita catastale
può essere richiesto dall’Ufficio dell’Agenzia del territorio fornendo i dati catastali
dell’immobile.
La rendita verrà successivamente rivalutata del 5 percento per compensare l’errore
dato dall’estimo (25 percento per il gruppo T).
51

4.4.2.4 Moltiplicatori Catastali e Aliquote
Per ogni categoria è presente un moltiplicatore catastale che andrà moltiplicato
per la rendita catastale rivalutata, il risultato di questa operazione è chiamata base
imponibile. I moltiplicatori[40] sono i seguenti:
• 160: Per le categorie C/2, C/6, C/7 e tutto il gruppo A tranne la categoria
A/10;
• 140: Per il gruppo B e le categorie C/3, C/4, C/5;
• 135: Per il gruppo T;
• 110: Per il gruppo T che abbia come possessore un coltivatore diretto o un
imprenditore agricolo professionale;
• 80: Per le categorie A/10 e D/5
• 65: Per il gruppo D tranne la categoria D/5;
• 55: Per la categoria C/1
Successivamente la base imponibile viene moltiplicata per l’aliquota della categoria
dell’immobile[41]a cui fa riferimento; questa che può essere modificata dal Comune
dov’è locato l’immobile, se cos`ı non fosse, allora viene applicata l’aliquota stan-
dard relativa alla categoria dell’immobile. Il risultato dell’operazione è chiamata
Imposta IMU.
Fig. 4.3: Aliquote Catastali[42].
52

4.4.2.5 Percentuale, Mesi di possesso e Detrazioni
L’imposta tiene anche conto dei mesi e la percentuale di possesso dell’immobile,
per ottenere l’importo da pagare di un determinato immobile posseduto X mesi in
una percentuale Y, successivamente vengono poi sottratte le detrazioni Imu (che
vengono date in determinati casi)[43].
Risultato = ImpostaImu ∗
X
12
∗
Y
100
− DetrazioniImu
4.4.2.6 Esenti parziali/totali
L’imposta offre uno sconto totale o parziale in base a determinati fattori quali
la tipologia, l’ubicazione, lo stato, lo scopo ed il possessore dell’immobile[44].
Sono esenti al 100% gli immobili:
• Appartenenti allo Stato;
• Appartenenti a regioni, province, comuni, comunità montane, consorzi dei
enti (non soppressi), enti del servizio sanitario nazionale destinati a scopi
istituzionali;
• Destinati ai compiti istituzionali posseduti dai consorzi tra enti territoriali,
prevista all’art. 7, comma 1, lett. a), del D. Lgs. n. 504 del 1992;
• Classificati nel gruppo E
• Destinati ad usi culturali di cui all’art. 5-bis del D.P.R. 29 settembre 1973, n.
601, e successive modificazioni;
• Destinati esclusivamente all’esercizio del culto, purché compatibile con le di-
sposizioni degli artt. 8 e 19 della Costituzione, e le loro pertinenze;
• Di proprietà della Santa Sede indicati negli artt. 13, 14, 15 e 16 del Trattato
lateranense;
• Appartenenti agli Stati esteri ed alle organizzazioni internazionali per i quali
è prevista l’esenzione dall’imposta locale sul reddito dei fabbricati in base ad
accordi internazionali resi esecutivi in Italia;
• Utilizzati dai soggetti di cui all’art. 73, comma 1, lett. c), del TUIR, destinati
esclusivamente allo svolgimento con modalità non commerciali di attività as-
sistenziali, previdenziali, sanitarie, didattiche, ricettive, culturali, ricreative e
sportive, nonché delle attività di cui all’art. 16, lett. a), della legge 20 maggio
1985, n. 222;
• Rurali ad uso strumentale di cui all’art. 9, comma 3-bis, del D. L. n. 557 del
1993, ubicati nei comuni classificati montani o parzialmente montani di cui
all’elenco dei comuni italiani predisposto dall’ISTAT;
• Appartenti alla categoria T e ricadenti in aree montane o di collina individuati
dalla circolare del Ministero delle Finanze n. 9 del 14/06/1993
53

• Appartenti alla categoria T e posseduti e condotti da coltivatori diretti (CD)
o da imprenditori agricoli professionali (IAP);
• Appartenti alla categoria T e ubicati nei comuni delle isole minori di cui
all’allegato A annesso alla legge 28/12/2011 n.448;
• Appartenti alla categoria T e con immutabile destinazione agrosilvo-pastorale
a proprietà collettiva indivisibile e inusucapibile;
• Ad uso abitativo ma non locata (con le relative pertinenze) posseduta da
anziani o disabili residenti in modo permanente presso un istituto di ricove-
ro/sanitario;
• Aventi il ruolo di prima casa appartenenti fra la categoria A/2 e A/7 (Legge
di stabilità 2014) con le pertinenze (C/2, C/6, C/7)) ad essa correlata (valida
solo per un’istanza per ogni categoria di pertinenza).
Sono esenti al 25% gli immobili locati a canone concordato, cioè relativo a
contratti dalla durata minima di 5 anni 4
che abbiano importi minimi e massimi
stabiliti a livello locale, dal Comune in cui risiede l’immobile.
Sono esenti al 50% sull’imposta imu gli immobili per il comodato d’uso gratuito
genitori-figli, cioè la consegna gratuita di un immobile per un certo lasso di tempo
a genitori/figli. Questo è valido solo se:
• Il contratto di comodato è stato regolarmente registrato presso l’Agenzia delle
Entrate;
• Il comodante possiede un solo immobile sul territorio nazionale e che risieda e
dimori abitualmente nello stesso comune in cui è situato l’immobile concesso
in comodato;
• Il comodante oltre a possedere l’immobile dato in comodato, possiede nello
stesso comune un altro immobile adibito a propria abitazione principale, fatta
eccezione delle abitazioni di categorie catastali A/1, A/8 e A/9.
È presente uno sconto del 50% sulla base imponibile dell’immobile per i fabbri-
cati di interesse storico o artistico, e per i fabbricati dichiarati inagibili (accertati
dall’ufficio tecnico comunale).
4.5 Implementazione IMU
Dopo aver discusso con l’Avv. Lonoce Antonino dell’imposta ed aver appreso i
concetti necessari, siamo passati alla codifica. In questa sezione mostriamo breve-
mente i risultati ottenuti.
Sfortunatamente l’implementazione dell’IMU non sarà dettagliata come quella del-
l’IRPEF a causa della sua enorme complessità e della grandissima articolazione delle
sue variabili, ciò avrebbe richiesto un numero maggiore di colloqui con l’avvocato.
Inoltre un’analisi più approfondita avrebbe richiesto un’implementazione più det-
tagliata con strutture dati che sono ancora in fase di sviluppo nella piattaforma
OpenFisca. Inizialmente abbiamo implementato la base dell’IMU:
4
Il contratto è nella forma 3 + 2 cioè dura 3 anni ma è previsto un rinnovo tacito di 2 anni.
54

• Categorie catastali;
• Aliquote;
• Variabili booleane per verificare delle condizioni;
• Variabili basilari dell’immobile (base imponibile, valore dell’immobile...)
Successivamente abbiamo implementato tutte le formule utili per calcolare l’IMU
su:
• Aree fabbricabili;
• Seconda casa;
• Prima casa;
• Immobili a canone concordato;
• Immobili con interesse storico/artistico;
• Immobili inagibili;
• Immobili posseduti in una determinata percentuale;
• Immobili posseduti solo per un numero definito di mesi;
• Pertinenze dell’immobile;
• Terreni.
Tutto ciò è stato anche testato durante l’implementazione in modo che le nuove
funzionalità non intacchino le precedenti. Il codice riguardante l’IMU è disponibi-
le al seguente URL: https://github.com/openfisca/openfisca-italy/
tree/Initizialize_open-fisca-italy/openfisca_italy5
5
Attualmente le funzionalità sopra riportate non si trovano sul branch master
55

5. Openfisca Managing Tool
Avendo già descritto, anche se in minima parte, il sistema openfisca-italy, pos-
siamo ora descrivere l’argomento centrale della tesi, il software di nostra concezione
Openfisca Managing Tool (repository Github: https://goo.gl/s9kFhz).
In particolare, descriveremo le motivazioni che ci hanno spinto a sviluppare questo
software, l’architettura e le varie funzionalità, descrivendole dapprima in maniera
teorica con l’ausilio di diagrammi per poi passare alla descrizione dell’
implementazione, con l’ausilio di immagini derivate dal software .
5.1 Scopo del software
Durante lo sviluppo del sistema openfisca-italy abbiamo constatato che sarebbe
impossibile, per il legislatore, definire nuove riforme, variabili , parametri o effettuare
analisi senza l’ausilio di un team di sviluppatori. Da questa premessa, nasce l’idea
Openfisca Managing Tool, che si propone di essere un software user-friendly per
la gestione e l’analisi di un generico sistema fiscale openfisca.
56

Openfisca Managing Tool: a tool to manage fiscal sistems

Openfisca Managing Tool: a tool to manage fiscal sistems

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Openfisca Managing Tool: a tool to manage fiscal sistems

Similar to Openfisca Managing Tool: a tool to manage fiscal sistems (20)

Openfisca Managing Tool: a tool to manage fiscal sistems