REQUISITI PER L’IMPLEMENTAZIONE DEL SISTEMA GESTIONALE-CONTABILE MICROSOFT DYNAMICS BUSINESS CENTRAL

Allegato n. 2.2 al Capitolato speciale descrittivo e prestazionale

PROCEDURA PER L’ACQUISIZIONE DI SERVIZI DI MIGRAZIONE, MANUTENZIONE, SVILUPPO EVOLUTIVO E FORMAZIONE DELLA PIATTAFORMA ERP AZIENDALE (DA MS NAV A MS BUSINESS CENTRAL)

CPV: 72230000-6 Servizi di sviluppo di software personalizzati, 72611000-6 Servizi di assistenza tecnica informatica

CIG: 911099139F

CUP: F81B20002910002

Pag. 1 a 26

Il presente documento è allegato al Capit\olato relativo alla procedura in oggetto (vedi intestazione) di cui costituisce parte integrante. Il documento contiene la descrizione dei principali requisiti richiesti per l’impostazione/implementazione della nuova piattaforma ERP basata su MicroSoft Dynamics Business Central.

Si evidenzia come ulteriori requisiti, rispetto a quelli di seguito descritti, potranno essere introdotti all’avvio dell’attività di Analisi e Progettazione (vedi Capitolato §2.1.1.1) qualora ritenuto necessario da parte della Stazione Appaltante.

INTRODUZIONE

Il presente documento ha lo scopo di riassumere le principali esigenze e soluzioni ipotizzate per l’implementazione del nuovo sistema gestionale-contabile Microsoft Dynamics Business Central da fruire in modalità SaaS (di seguito denominato Sistema BC) presso Lazio Innova SpA.

L’ipotesi di copertura funzionale per i processi oggetto di interesse è stata effettuata tenendo conto dei

requisiti raccolti dalle seguenti aree aziendali:

• Area Contabilità e Finanza;

• Area Controllo di Gestione;

• Area Ufficio Acquisti;

• Area Information Technology (Transizione Digitale).

Nei capitoli successivi, sono riportate le soluzioni ipotizzate per ogni processo e/o area di interesse.

1. PROCESSI E MODULI

1.1. CONTABILITÀ GENERALE

Le esigenze emerse in area Contabilità Generale e i moduli e le funzionalità che potranno essere oggetto di configurazione e implementazione sul sistema sono le seguenti.

1.1.1. Piano dei conti

Lazio Innova ha la necessità di ricodificare l’attuale Piano dei Conti, in uso nel Sistema NAV, in aderenza alle disposizioni di cui all’art. 2423 ter x.x. xxxxxxxxxxx x xxxxxxxxxxxxxx xxxx xxxxxx xx xxxxxxxx xxxxx xxxxxxxxxxxxxxx xxxxxxxxx (XXXXXXX) e della Regione Lazio.

1.1.2. Stampe e adempimenti fiscali

Ai sensi della normativa vigente e in coerenza con il programma aziendale di digitalizzazione, Lazio innova intende introdurre la tenuta dei registri contabili e fiscali obbligatori con sistemi elettronici, derogando quindi agli obblighi di stampa, nel rispetto degli obblighi di conservazione digitale.

Verranno mantenute eventuali stampe standard su tale materia previste dal sistema.

Dovrà essere, inoltre possibile gestire i seguenti adempimenti fiscali, a titolo esemplificativo e non esaustivo:

• Lazio Innova, quale società soggetta alla fatturazione elettronica verso la pubblica amministrazione (FatturaPA), dovrà gestire la fatturazione attiva e passiva in conformità alla normativa di riferimento (per i dettagli della necessaria integrazione con un modulo intermediario di integrazione della fattura elettronica si rimanda al successivo §3.1);

• Certificazione Unica;

• Comunicazioni IVA periodica.

Lazio innova ha l’esigenza di gestire le stampe standard relative al bilancio d’esercizio.

1.1.3. Gestione IVA

Lazio Innova in qualità di società controllata, ai sensi dell'articolo 2359, primo comma, nn. 1), del codice civile, direttamente dalla Regione Lazio è soggetta alla disciplina della scissione dei pagamenti così detta split payment.

Pertanto, il sistema dovrà gestire sia lo split payment attivo che lo split payment passivo. (vedi successivo §1.2.8).

Dovrà essere possibile la gestione di registri IVA dedicati a Tipi operazione differenti (ad esempio PA/non PA).

1.1.3.1.Contabilità separata IVA

Lazio Innova ha la necessità di gestire liquidazioni separate. Nel Sistema BC si utilizzeranno differenti codici attività da attribuire a monte ad ogni fattura/nota di credito, per poi liquidare l’IVA in maniera separata, in funzione del codice attività.

1.1.3.2.Liquidazione IVA pro-rata

Lazio Innova attualmente non ha la necessità di gestire il calcolo del pro-rata in fase di liquidazione IVA. Nel caso tale obbligo si presentasse nel 2022 sarà necessario sviluppare le relative funzionalità.

Si prevede, in questa eventualità, di realizzare un report personalizzato che consenta tale attività. In alternativa è possibile stabilire a monte la % di detraibilità, nel Setup registrazioni IVA, da applicare ai protocolli da registrare, lanciando la liquidazione IVA standard. Per questa ultima soluzione è necessario stabilire ogni anno le % di detraibilità da attribuire di volta in volta ai codici IVA interessati, bonificando eventuali movimenti con

% di detraibilità errata.

In entrambe le soluzioni proposte, a fine esercizio, il calcolo della percentuale definitiva di detraibilità e la

rettifica dei calcoli effettuati nelle liquidazioni periodiche andrà effettuata manualmente dall’utente.

1.1.4. Gestione ritenute e contributi INPS

La gestione delle ritenute dovrà prevedere anche le funzionalità riferite ai fornitori soggetti a Regime dei Minimi ed eventuali altri regimi oltre la rilevazione di eventuali contributi integrativi previdenziali (ad es. Casse Ordini Professionali).

1.1.5. Prime note contabili

Le funzionalità standard del sistema dovranno essere integrate con tools personalizzati o soluzioni equipollenti

per l’importazione delle seguenti scritture, prodotte da sistemi esterni:

• Import Paghe;

• Import Paghe Collaboratori.

1.1.6. Gestione dimensioni

Per ogni registrazione contabile sarà possibile specificare le dimensioni/attributi necessarie per effettuare poi analisi di contabilità analitica sia tramite strumenti standard come l’analisi per dimensioni, sia tramite il modulo di controllo budget (vedi successivo §1.2.7).

Verrà implementata la creazione automatica del corrispondente valore di dimensione alla creazione delle seguenti anagrafiche:

• Fornitore;

• Cliente;

• Commessa;

• Task.

1.1.7. Gestione competenze

Lazio Xxxxxx potrebbe dover gestire le scritture di accantonamento/ratei e risconti di fine anno o infrannuali in maniera automatizzata a partire da ordini/ordini di reso/fatture/note di credito/prime note. Dovranno essere previsti moduli aggiuntivi o soluzioni equipollenti per gestire:

• Date competenza (inizio e fine) su ogni tipo di registrazione contabile;

• Calcolo ratei e risconti con possibilità di elaborazione mensile o annuale;

• Proposta scritture accantonamento FDE e FDR sulla base di carichi/spedizioni non fatturate. Per maggiori dettagli si rimanda al successivo §3.3.

1.1.8. Cash Flow

Lazio Innova valuterà, in funzione alle esigenze, eventuali personalizzazioni da apportare alla gestione offerta dalle funzionalità standard.

1.1.9. Fondi in gestione

Nell’attuale Sistema NAV è in uso un modulo add-on specifico che permette agli utenti di effettuare registrazioni e analisi in ambiente simulato (Extra-Contabile).

Nel nuovo sviluppo Lazio Innova tenderà a gestire la contabilità dei Fondi in gestione attraverso la creazione

di “società” ad hoc.

All’interno di dette “società” sarà necessario codificare diverse “dimensioni” a seconda dei programmi regionali e/o comunitari che Lazio Innova dovrà gestire e per i quali dovrà effettuare rilevazioni contabili distinte.

1.1.10. Altri adempimenti

È emersa l’esigenza di estrarre dal Sistema BC i seguenti tracciati:

• Conti Pubblici Territoriali (CPT) Modello di rilevazione delle entrate à Tracciato Excel in cui l’utente riporta i saldi dei conti del Piano dei conti riclassificato in base ad esigenze dettate dagli adempimenti da assolvere;

• Conti Pubblici Territoriali (CPT) Modello di rilevazione delle spese à Tracciato Excel in cui l’utente riporta i saldi, suddivisi per attributi di colonna, dei conti del Piano dei conti riclassificato in base ad esigenze dettate dagli adempimenti da assolvere;

• Sistema di Monitoraggio delle Controllate della Regione Lazio (SIMOC) pilota flusso à Tracciato Excel in cui l’utente riporta i saldi, suddivisi per mese, dei conti del Piano dei conti riclassificato in base ad esigenze dettate dagli adempimenti da assolvere.

• Sistema di Monitoraggio delle Controllate della Regione Lazio (SIMOC) pilota Patrimoniale à Tracciato Excel in cui l’utente riporta i saldi dei conti del Piano dei conti riclassificato in base ad esigenze dettate dagli adempimenti da assolvere.

• Trasparenza à Tracciati Excel in cui l’utente riporta i dati necessari per i relativi adempimenti normativi come a mero titolo esemplificativo e non esaustivo:

- dati sui pagamenti Art. 4 bis c. 2 D.Lgs. 33/2013;

- indicatore dei pagamenti Art. 33 D.Lgs. 33/2013 (corrisponde al report omonimo di cui al successivo §1.2.6). Si ipotizza la gestione della categoria come attributo dimensionale standard e successivo aggancio conto XX.XX/xxxxxx dimensione categoria.

• Piattaforma dei Crediti Commerciali gestita dal MEF.

Si ipotizza la gestione dei tracciati attraverso le funzionalità standard di “Analisi per dimensioni”, “Situazioni contabili” o “Sintesi dimensioni C/G” o, in alternativa, mediante reportistica mirata.

1.1.11. Bilancio quadrimestrale

Lazio Innova ha l’esigenza di poter effettuare stampe di bilancio quadrimestrali sfruttando la possibilità, presente in Business Central, di estrarre situazioni contabili, bilanci di verifica (anche di dettaglio) e analisi per dimensioni filtrando per periodi. Tali stampe possono includere sia i movimenti contabili sia i movimenti extra-contabili riferiti a prime note creati da utenti o accantonamenti/ratei/risconti non registrati in definitivo (il modulo extra-contabile e competenze è dettagliato nel successivo §3.3).

1.2. CICLO PASSIVO

1.2.1. Anagrafica fornitore

Dovrà essere gestita a sistema un’anagrafica fornitore fittizia da associare alle Richieste d’Acquisto (di seguito RdA) in fase di inserimento da parte del richiedente. Al momento della conversione della RdA in Ordine d’Acquisto (di seguito OdA), terminato il workflow approvativo sulla RdA, l’ufficio acquisti inserirà il fornitore aggiudicatario dell’incarico. Le anagrafiche fornitori verranno, di volta in volta, inserite dall’ufficio Contabilità e Finanza.

È richiesta una personalizzazione per la gestione degli ordini e pagamenti verso fornitori per tipologie: è

presente nell’attuale Sistema NAV la gestione di ordini e pagamenti per tipologia “Dipendente Pubblico”.

1.2.2. Anagrafica articoli

Verranno utilizzate anagrafiche articoli “di servizio” da attribuire ad ogni riga di RdA, Xxxxxx e Ordini programmati. L’utilizzo degli articoli permetterà ai richiedenti la creazione di RdA e Ordini senza dover scegliere il relativo conto contabile, poiché la mappatura articolo/conto verrà effettuata a monte attraverso l’attribuzione delle categorie articolo/servizio ai vari articoli.

Inoltre, sarà possibile agganciare ad ogni anagrafica articolo l’obbligo di valorizzazione delle dimensioni di

default (Commessa, Task) e la dimensione “Voce di Spesa” da riportare in riga una volta selezionato l’articolo.

1.2.3. Gestione Ciclo Passivo

Per quanto riguarda la gestione del ciclo passivo, contestualmente al Go-Live del nuovo Sistema BC, si è ipotizzata la possibilità di apportare alcune modifiche alle procedure in essere nel sistema NAV, con l’obiettivo di rendere più efficace la gestione dei workflow approvativi delle Richiesta di acquisto (RdA). I workflow approvativi saranno, in funzione di un apposito setup, integrati il controllo di budget (per maggiori dettagli si rimanda al successivo §1.2.7).

Lazio Innova ha le seguenti esigenze connesse alla gestione del ciclo passivo:

1) Gestione in Business Central della RdA/OdA: la RdA è identificata in Business Central con l’offerta di acquisto, che poi verrà convertita in Ordine di acquisto (OdA) a valle del workflow. Il controllo di capienza e l’impegno scatteranno all’invio in approvazione della RdA (come dettagliato nel successivo §1.2.7);

convertita in ordine programmato; Secondaria – agganciata all’ordine programmato e convertita in

ordine).

3) Gestione in Business Central di Contratti XX.XXX: il documento in Business Central viene identificato con l’ordine programmato (sottoposto a workflow approvativo e controllo di budget). Da ogni ordine programmato verranno generati ordini secondari, ciascuno dei quali da avviare a workflow approvativo (dovrà essere previsto il controllo budget durante il workflow approvativo). Gestione assimilabile al caso due, al netto di eventuale flusso approvativo.

Per agevolare gli accertamenti parziali sugli ordini sarà necessario procedere alla valorizzazione del campo “Costo unitario”, di “Righe acquisto”, con il valore “1,00” e del campo “Quantità” con un ammontare pari all’importo. È da prevedere una personalizzazione per la valorizzazione del campo “Costo unitario” sempre con il valore “1,00”, il campo potrà essere non editabile in funzione di un apposito campo di Setup contabilità fornitori. L’editabilità del campo potrà essere consentita in funzione di un Setup agganciato alle singole anagrafiche richiamate in righe acquisti (Conto C/G, Articolo, Cespite, Risorsa, Addebito (articolo) – per gestire, ad esempio, gli acquisti di giornate per risorse esterne (il cui costo è a giornata).

1.2.3.1.Gestione approvazioni

Da standard è possibile parametrizzare workflow per varie tipologie di documento, tra cui RdA, Ordini, Ordini programmati. I workflow possono essere parametrizzati in base a Driver di testata documento (importi, dimensioni globali CDR/Servizi) e per ciascun workflow è possibile configurarne gli approvatori. È possibile stabilire la scadenza delle approvazioni (prevedere una eMail di sollecito sulle approvazioni tardive, da notificare all’approvatore coinvolto) e delegare automaticamente (in base al numero di giorni selezionato rispetto alla scadenza stabilita) o manualmente (funzione “Delega”) l’approvazione del documento all’utente sostituto se l’approvatore originario non ha ancora approvato il documento. Inoltre, è possibile, dalle statistiche del documento, visualizzare il mittente, l’approvatore di turno, data/ora invio in approvazione e la scadenza dell’approvazione (configurata per lo specifico workflow approvativo).

Solo gli utenti facenti parte del workflow e l’amministratore delle approvazioni (Amministratore di Sistema),

dovranno poter visualizzare tutte le approvazioni.

Da standard le RdA convertite in OdA vengono eliminate dal sistema (è possibile archiviarle automaticamente nelle tabelle di archivio) e le approvazioni relative alla RdA andranno ad essere attribuite all’ordine di acquisto generato e non risulteranno visibili dalle schede di archivio.

Rispetto, quindi, all’attuale sistema NAV, le approvazioni relative a RdA convertite in ordini non saranno più visualizzabili. Allo scopo di poter visualizzare le approvazioni riferite a RdA convertite in ordini è possibile seguire due strade implementative alternative:

1) Le approvazioni verranno agganciate alla RdA archiviata e la RdA verrà eliminata dal sistema alla conversione in ordine.

2) La RdA non verrà eliminata dal sistema dopo la conversione in ordine e verranno conservate le approvazioni riferite alla RdA convertita. Si dovranno prevedere schermate ad hoc per la visualizzazione delle RdA convertite in ordine con relative approvazioni (sola visualizzazione).

Lazio Innova ha, inoltre, l’esigenza di notificare all’approvatore, laddove siano presenti commenti relativi al movimento di approvazione, la presenza di commenti.

A tal scopo è possibile prevedere una eventuale personalizzazione che consenta, al click dei tasti “Approva”, “Rifiuta” o “Delega”, di visualizzare la lista dei commenti relativi al documento che si sta approvando, rifiutando o delegando e poi confermare l’operazione per procedere all’approvazione, rifiuto o delega. Verranno visualizzati tutti i commenti inseriti da ciascun approvatore e ciascun commento non potrà essere modificato. I commenti inoltre saranno riportati nella stampa delle RdA, Ordini, Ordini programmati.

1.2.3.3.Gestione RdA/OdDA

Sono possibili tre scenari alternativi di gestione:

1) Scenario 1: RdA su unico Servizio/CDR e con più commesse in riga e OdA su unico Servizio/CDR;

2) Scenario 2: RdA su unico Servizio/CDR e con più commesse in riga e OdA su più Servizi/CDR;

3) Scenario 3: RdA su più Servizi/CDR e con più commesse in riga e OdA su più Servizi/CDR.

A prescindere dai possibili scenari, il processo di gestione nel caso di gestione RdA/OdA sarà strutturato secondo gli step descritti di seguito:

• INSERIMENTO RdA: avrà luogo con la creazione su Business Central dell’“Offerta di acquisto” da

parte di un richiedente del Servizio (CDR).

Sarà prevista la possibilità di creare le RdA intestandole ad un fornitore fittizio, che dovrà essere sostituito con quello effettivo prima della conversione della RdA in OdA.

La RdA dovrà essere sottoposta a workflow approvativo: il richiedente invierà pertanto la RdA in approvazione e il Sistema procederà all’impegno di budget.

Per dettagli sul controllo di budget si rimanda al successivo §1.2.7.

• APPROVAZIONE RdA: il flusso approvativo sul documento dipenderà dai seguenti driver e gli approvatori potranno essere stabiliti per ogni workflow creato:

o Centro di responsabilità;

o Eventualmente in base all’Importo totale del documento.

Non sono previste, da standard, modifiche su RdA in corso di approvazione. In caso di modifiche necessarie, verrà riaperto il documento, modificato e riavviato a flusso approvativo.

Come descritto nel successivo §1.2.7, la RdA impegnerà il budget all’invio in approvazione, per cui sarà necessario riaprire la RdA affinché si possa procedere ad eventuali modifiche della RdA stessa. Tutte le richieste di modifica per RdA in corso di approvazione saranno centralizzate verso un unico utente (Amministratore di Sistema – che nel Sistema BC sarà anche Amministratore approvazioni), il quale procederà ad annullare le richieste di approvazione (se il documento è in corso di approvazione) o riaprire il documento (se il documento è rilasciato), apporre le modifiche e rinviare in approvazione il documento. Potrà delegare le approvazioni alla propria utenza, laddove non si voglia attendere che gli approvatori riapprovino il documento, ed approvare lui stesso il documento.

• CREAZIONE OdA: la creazione dell’ordine di acquisto a sistema a partire dalla RdA potrà avvenire, a carico dell’ufficio acquisti, unicamente a valle dell’approvazione della RdA e della valorizzazione su quest’ultima del fornitore effettivo a cui intestare l’ordine di acquisto. Sarà possibile modificare gli ordini di acquisto (per ogni modifica occorrerà riaprire l’ordine e, una volta terminate le operazioni, rilasciare l’ordine al fine di aggiornare gli impegni di budget).

• REGISTRAZIONE ENTRATA MERCE (ACCERTAMENTO): avverrà mediante la registrazione del carico (entrata merce/ricezione servizio). Il sistema NAV attualmente in uso prevede una personalizzazione attraverso la quale vengono effettuate le scritture di accantonamento automatico Costo a Fatture da ricevere in XX.XX e “Utilizzo” in Commessa. Questa personalizzazione verrà esclusa dal perimetro di progetto. Per gli accantonamenti Costo a Fatture da ricevere in XX.XX verranno utilizzati gli strumenti descritti nel precedente §1.1.7.

• CREAZIONE E REGISTRAZIONE FATTURA PASSIVA: di competenza degli utenti dell’ufficio amministrativo, avverrà elaborando la fattura elettronica importata a sistema e collegando la stessa ai carichi registrati a sistema.

Per l’integrazione con il modulo intermediario per l’automatizzazione dell’importazione XML delle

fatture passive si rimanda al successivo §3.1.

Vengono riportati, nei paragrafi seguenti, tre diversi scenari di gestione RdA/OdA ipotizzati da Lazio Innova. Tali scenari hanno carattere indicativo ed è facoltà degli offerenti proporre un’ipotesi alternativa in sede di offerta Tecnica. Lazio Innova si riserva di operare una scelta definitiva in fase di conferma dei requisiti. In partenza, si ritiene utile evidenziare lo Scenario 1 in quanto presenta il minor impatto sull’impianto standard di gestione dei workflow e di profilazione ed è configurabile sulle base delle attuali logiche presenti dell’extension di Controllo Budget.

1.2.3.3.1.Scenario 1

Di seguito vengono illustrati i dettagli relativi al primo scenario.

IPOTESI SCENARIO 1

Hp1: RDA su unico Servizio/CDR ma con più commesse in riga

Hp2: Workflow approvativo RDA basato su driver di testata del documento

Hp3: ODA su unico Servizio/CDR

Hp4: registrazione entrata merce per verifica conformità fattura passiva

Hp5: richiedenti con accesso a sistema per caricamento RDA ed entrata merce

Processo

Condizione

Inserimento RDA

Approvazione RDA da parte

di ACQ.

Approvazione RDA da parte di ulteriori utenti da definire

Creazione ODA

Sempre

Owner

Richiedente Servizio/CDR Responsabile Ufficio Acquisti Utente/Utenti da definire

Ufficio Ac

Attività

Inserimento RDA su fornitore fittizio e s servizio.

Verifica conform

RDA approvata

Registrazione entrate merce

Verifica conformità fattura passiva

Registra

Nel caso di RdA multiservizio si potrebbero utilizzare gli ordini programmati inserendo righe diverse per servizio: da ciascuna riga dell’ordine programmato possono essere generati ordini di acquisto mono-servizio e avviati a workflow approvativo.

1.2.3.3.2.Scenario 2

Di seguito vengono illustrati i dettagli relativi al secondo scenario.

Hp1: RDA su unico Servizio/CDR ma con più commesse in riga

Hp2: workflow approvativo RDA basato su driver di testata del documento Hp3: ODA su più Servizi/CDR (personalizzazione)

Hp4: registrazione entrata merce per verifica conformità fattura passiva

Hp5: richiedenti con accesso a sistema per caricamento RDA ed entrata merce solo su righe ODA di propria competenza (personalizzazione)

IPOTESI SCENARIO 2

Processo	Condizione	Owner	Attività
Inserimento RDA		Richiedente Servizio/CDR	Inserimento RDA su fornitore fittizio e su unico servizio.
Approvazione RDA da parte di ACQ.	Sempre	Responsabile Ufficio Acquisti	Verifica conformità da parte di utente area Acquisti.
Approvazione RDA da parte di utenti da definire.	Sempre	Utente/Utenti da definire.	RDA approvata in base a driver di testata del documento.
Creazione ODA	RDA approvata	Ufficio Acquisti	Conversione in ODA e inserimento CIG e allegati.
Aggregazione RDA in ODA	RDA approvata	Ufficio Acquisti	Possibilità di richiamare in ODA righe di RDA di servizi differenti.
Registrazione entrate merce		Richiedente Servizio/CDR	Registrazione entrata merce/ricezione servizio a carico dell'utente del Servizio/CDR solo sulle righe di propria competenza.
Verifica conformità fattura passiva		Utente/Utenti da definire	Aggancio a ordini e carichi da area di Staging fatturazione elettronica passiva.
Registrazione fattura passiva		Utente APPROVATORE	Elaborazione fattura con aggancio al Carico.

Dal punto di vista di profilazione è necessaria una personalizzazione sul Sistema per consentire una logica di visualizzazione del documento per riga riferita al Servizio/CDR di appartenenza.

Dal punto di vista del Controllo Budget è necessaria una personalizzazione sulla gestione degli impegni di

budget in fase di passaggio da RdA a OdA.

1.2.3.3.3.Scenario 3

Di seguito vengono illustrati i dettagli relativi al terzo scenario.

IPOTESI SCENARIO 3
Hp1: RDA su più Servizi/CDR (personalizzazione)
Hp2: workflow approvativo RDA (personalizzazione)	basato su driver di riga del documento
Hp3: ODA su più Servizi/CDR (personalizzazione)
Hp4: registrazione entrata merce per verifica conformità fattura passiva
Hp5: richiedenti con accesso a sistema per caricamento RDA ed entrata merce solo su righe ODA di propria competenza
Hp6: approvazione al pagamento fattura a RUP/DEC contratto*

Lo scenario presenta poca fluidità sul processo, che risulta essere quindi frammentato (per la conclusione di ciascun step approvativo occorrerebbe attendere che tutti gli utenti abbiano approvato le righe del proprio servizio), inoltre non risulta definito l’owner dell’inserimento della RdA.

Per questo scenario la soluzione tecnica proposta è la gestione di un documento “padre” con righe per singolo servizio/CDR. Da ciascuna riga verranno generate le RdA “figlie” (mono servizio/CDR) da avviare a flusso approvativo. Il documento “padre” avrà al suo interno il richiamo alle RdA/Ordini generati.

Dal punto di vista di profilazione è richiesta una personalizzazione sul Sistema BC per consentire una logica

di visualizzazione del documento “padre” per riga riferita al Servizio/CDR di appartenenza.

1.2.3.4.Gestione Accordi Quadro/Ordini programmati XX.XXX.

Il processo di ciclo passivo nel caso di gestione dei contratti a prestazioni multiple sarà strutturato secondo gli step descritti di seguito:

• INSERIMENTO ORDINE PROGRAMMATO: avrà luogo con la creazione su Business Central dell’“Ordine di acquisto programmato” da parte dell’Ufficio Acquisti o di un richiedente del Servizio (CDR).

L’ordine programmato sarà intestato al fornitore intestatario del contratto, laddove sia noto il fornitore, e verranno inserite righe distribuite su commesse, task e voci di spesa. La somma degli importi di riga corrisponderà all’importo del contratto.

Laddove il fornitore non sia noto a priori verrà inserito un fornitore fittizio che dovrà essere sostituito, una volta terminato il processo di aggiudicazione dell’incarico, con quello effettivo a valle del rilascio dell’ordine programmato (a conclusione del workflow approvativo).

Rispetto all’attuale sistema NAV, allo scopo di snellire il processo di Ciclo Passivo attualmente in uso, gli ordini programmati non verranno generati a partire da RdA principali, ma verranno creati direttamente da lista ordini programmati e gli ordini discendenti dagli ordini programmati saranno creati direttamente dagli ordini programmati di riferimento.

• VERIFICA ODP: verrà gestito un workflow standard per approvare l’ODP (ufficio ACQà ufficio Contabilità e Finanza à Ufficio CDG non sono ancora stati censiti gli approvatori): un workflow che non segua logica di driver di dimensioni.

• CREAZIONE OdA: la creazione dell’ordine di acquisto a sistema a partire dal contratto potrà avvenire, a carico dell’area richiedente. Sarà prevista la possibilità di emettere più ordini di acquisto da uno stesso contratto (ordine di acquisto programmato), con contestuale verifica della capienza dello stesso. É stata richiesta una eventuale personalizzazione per visualizzare, negli Ordini programmati, solo le righe di competenza del servizio/CDR di appartenenza.

• APPROVAZIONE OdA: ogni OdA dovrà essere approvato con relativo workflow di testata.

• REGISTRAZIONE ENTRATA MERCE: avverrà mediante la registrazione del carico (entrata merce/ricezione servizio).

Per l’integrazione con il modulo intermediario per l’automatizzazione dell’importazione XML delle

fatture passive si rimanda al successivo §3.1. Di seguito, uno schema riepilogativo di quanto illustrato.

Processo

Condizione Owner

Inserimento ODP

Ufficio Acquisti

Attività

Inserimento ODP come accordo quadro da p dell'ufficio acquisti con suddivisione rig Servizio/CDR.

Verifica ordine programmato

da parte di ACQ. Sempre

Responsabile Ufficio

Acquisti Verifica conformità

Verifica utenti da definire

Utente/Utenti da

definire

ODP

Creazione ODA

ODP approvato Richiedente CD

Approvazione ODA

Sempre

Registrazione entrate merce

Verifica conformità f passiva

Regist

1.2.4. Scheda RdA, Ordine, Ordine Programmato

Sono state analizzate le schede RdA, Ordine e Ordine programmato in “Business Central” e dovranno essere integrati i seguenti campi necessari:

• Nr. Protocollo: verrà valorizzato dagli utenti in base al protocollo attribuito dal Sistema di protocollazione;

• CIG: verrà valorizzato dagli utenti in base al CIG del contratto;

• CUP: verrà valorizzato dagli utenti in base al CUP del contratto;

• Oggetto: verrà valorizzato dagli utenti in base all’oggetto della RdA;

• Modalità affidamento: verrà valorizzato dagli utenti in base alla modalità di affidamento dell’incarico;

• Tipologia acquisto: verrà valorizzato dagli utenti in base alla tipologia di acquisto che viene effettuata;

• Ordinante: verrà valorizzato dagli utenti in base all’utente responsabile del servizio che ha richiesto

l’acquisto.

• Note aggiuntive: verrà visualizzato in maschera RdA, Ordini, Ordini programmati, Ordini di reso il campo standard “Note aggiuntive”

• Data/ora creazione RdA (da valorizzare con la data/ora effettive di creazione della RdA).

Le stampe RdA, Ordine, Ordine Programmato andranno valutate in funzione degli scenari implementativi considerati nel precedente §1.2.3. Nelle stampe saranno previsti tutti i campi attualmente gestiti nella stampa del Sistema NAV (rispetto agli attuali campi stampati si prevedrà l’aggiunta del campo “Note aggiuntive”).

Nella scheda dell’ordine verrà riportato il Nr. della RdA da cui è stato generato (fatta eccezione per lo scenario 2 di Gestione RdA/OdA in quanto l’ordine verrebbe creato aggregando righe provenienti da più RdA).

1.2.5. Gestione pagamenti

Per i pagamenti sarà possibile utilizzare il modulo relativo alle “Distinte fornitori” tramite il quale potranno essere richiamate in maniera automatica le partite fornitori aperte, inserendo eventuali filtri su fornitori o importi da elaborare. In tale predisposizione potranno essere incluse fatture, documenti di spesa ed eventuali righe manuali (per gestione anticipi) e saranno gestite in automatico anche le ritenute, se calcolate in fase di registrazione delle fatture.

Dalle distinte emesse sarà poi consentito procedere all’estrazione del tracciato XML per le disposizioni di pagamento e, una volta ricevuto feedback positivo sull’elaborazione del pagamento, si potrà effettuare a sistema la registrazione del pagamento che produrrà in automatico la contabilizzazione delle scritture “Debito a Banca” (movimentando in Dare il conto acceso al debito verso il fornitore liquidato).

L’area “Contabilità e Finanza” di Lazio Innova ha l’esigenza di ripartire l’importo in Avere della banca in base alle righe presenti nella distinta effetti fornitore: si prevede l’utilizzo di un report che permetta di visualizzare, a partire dal movimento di uscita di banca della distinta, gli importi dettagliati per fornitore.

Sarà, inoltre, possibile effettuare registrazione di pagamento tramite prime note da batch contabile

“Registrazione pagamenti”.

1.2.6. Reportistica contabile fornitori

Oltre ai report e le funzionalità standard messe a disposizione dal sistema è richiesto di riportare due report

attualmente in uso nell’attuale Sistema NAV:

• Scadenzario fornitori con integrazione delle seguenti informazioni:

o Numero fattura; Data fattura; Servizio; Commessa. Gestire il caso di multi- commessa in riga attualmente personalizzato.

• Indicatore dei pagamenti (includere anche i pagamenti parziali – attualmente non gestiti).

1.2.7. Controllo budget

Sul database Lazio Innova dovrà essere installata un modulo aggiuntivo o una soluzione equipollente volta a gestire il controllo budget e che in particolare dovrà consentire di:

a. importare a sistema il budget iniziale allocato sulle varie dimensioni di analisi budget;

b. verificare la capienza del budget durante la creazione e contabilizzazione dei documenti di ciclo passivo e altre registrazioni contabili e restituire un blocco in caso di incapienza;

c. monitorare, tramite l’apposita maschera di Analisi Budget, la situazione del budget residuo per le varie dimensioni di analisi.

Dove:

• Codice à Valori dimensioni associati alla dimensione indicata in “Mostra come righe”;

• Nome à Descrizione valore dimensione associato al campo “Codice”;

• Budget à Importo stanziato a budget;

• Richieste aperte in approvazione à Impegno delle RdA in approvazione (se si parametrizza il controllo budget sulle RdA solo al rilascio). Tale importo non impatta su residuo budget;

• Richieste aperte à Impegno RdA in approvazione (se si parametrizza il controllo di budget sulle RdA

all’invio in approvazione o rilasciate. Tale importo impatta su residuo budget;

• Contrattualizzato à Impegno ODP (se si parametrizza il controllo budget su ordini programmati);

• Impegnato à Impegno OdA;

• Contabilizzato consuntivo budget in C/G.

Per il dettaglio dei movimenti che concorrono al “Contabilizzato” Lazio Innova richiede di indicare anche il

Nr. Ordine (per fatture provenienti da Ordini o note di credito provenienti da Ordini di reso).

Le dimensioni impostate per le analisi di budget saranno le seguenti:

• “Commessa” à è anche dimensione di controllo budget;

• “Task” à è anche dimensione di controllo budget;

• “Voce di spesa” à non è dimensione di controllo budget.

Lazio Innova utilizzerà, oltre a Business Central, una soluzione specifica per gestire lo stanziamento e l’analisi degli scostamenti di budget. La soluzione – che sull’attuale Sistema NAV è rappresentata dall’applicativo Solver BI 360 e che dovrà essere interfacciata al Sistema BC – sarà comunicata da Lazio Innova in fase di conferma dei requisiti. Di seguito vengono riportati i macro-punti di processo:

1) Il budget verrà stanziato attraverso l’applicativo di budgeting dove gli utenti inseriranno le varie revisioni di budget: le revisioni di budget approvate verranno caricate sul Sistema BC mediante l’importazione di un tracciato: i dati verranno acquisiti in area di staging e, una volta effettuati i controlli di coerenza dati, il Sistema BC procederà alla creazione degli stanziamenti e delle righe di pianificazione di commessa sulla base dei dati acquisiti tramite il tracciato;

2) Sul Sistema BC verrà attivato il controllo di budget sulla base alle dimensioni Commessa/Task. Il controllo/impegno budget verrà effettuato dal Sistema BC:

a. All’invio in approvazione di RdA/rilascio (Richieste aperte), all’invio in approvazione/rilascio

Ordini programmati (Contrattualizzato - se tale funzionalità viene attivata in apposito Setup),

all’invio in approvazione/xxxxxxxx Xxxxxx (Impegnato), alla creazione ordini da XxX (impegnato);

b. Alla registrazione di fatture acquisto e prime note.

Il disimpegno budget verrà effettuato dal Sistema:

a. All’invio in approvazione/rilascio di ordini di reso acquisti;

b. Alla registrazione di note di credito acquisto/prime note.

3) L’applicativo di budgeting estrarrà dal Sistema BC le informazioni relative a impegnato/contabilizzato budget e sarà possibile analizzare eventuali scostamenti.

L’impegno/disimpegno di budget si aggiornerà all’eventuale modifica delle righe di ordini, ordini programmati e ordini di reso.

1.2.8. Funzionalità PA

Sul database Lazio Innova saranno installati moduli aggiuntivi o soluzioni equipollenti atti a gestire le peculiarità caratteristiche delle Pubbliche Amministrazioni e, in particolare, i seguenti processi:

• Gestione CIG;

• Gestione avanzata del Contratto;

o Gestione importo massimale del contratto;

o Gestione date validità Contratto;

• Gestione utenti Ciclo Passivo PA;

• Gestione DURC;

• Gestione split payment passivo;

• Gestione trattenute 0,5%.

Nei paragrafi successivi vengono riportate, brevemente, le descrizioni delle funzionalità PA ritenute di interesse per Lazio Innova.

Dovranno, inoltre, essere gestite anche le seguenti fattispecie, ancorchè non specificate nel presente documento:

• Gestione RTI (Raggruppamenti Temporanei di Impresa);

• Gestione della regolare esecuzione (cd. Servizio Reso) oppure del benestare al pagamento.

1.2.8.1.Gestione CIG

Il CIG (Codice Identificativo Gara), è un codice alfanumerico univoco e obbligatorio che identifica un contratto pubblico stipulato in seguito ad una gara d'appalto o affidato con una delle altre modalità consentite dal codice dei contratti pubblici.

Considerando gli scopi previsti dalle normative, gli obiettivi della funzionalità saranno i seguenti:

• censire i CIG da associare ai documenti del ciclo passivo;

• associare i CIG ai conti correnti bancari fornitori;

• introdurre dei controlli/vincoli in fase di elaborazione dei documenti del ciclo passivo;

• aggiungere l’informazione del CIG nei tracciati XML generati dalle distinte di pagamento.

1.2.8.2.Gestione avanzata contratto Dovrà essere possibile gestire:

• Importo massimale del contratto: è l’importo totale pagabile al netto dell’IVA, valutato dalle

stazioni appaltanti. Gli obiettivi della funzionalità sono i seguenti:

o Indicare l’importo massimale del contratto (all’interno dell’Ordine di acquisto programmato);

del contratto (Ordine di acquisto programmato) non superino l’indicazione dell’Importo

massimale previsto per tale contratto.

• Gestione della data validità contratto: la funzionalità consente l’inserimento da parte degli utenti, in ciascun contratto (ODP), di una data di inizio e fine validità del contratto e di permettere la creazione di ordini di acquisto, legati al contratto, solo se la data di lavoro è compresa all’interno del range di date di inizio/fine validità.

1.2.8.3.Gestione utenti Ciclo Passivo PA

La funzionalità permetterà la gestione delle seguenti figure in alcune fasi del Ciclo Passivo:

• RUP (Responsabile Unico del Procedimento);

• DEC (Direttore Esecutivo del Contratto).

Considerando la presenza di tali figure e di eventuali figure delegate a supporto delle stesse, l’obiettivo, della

funzionalità è quello di:

• associare i vari utenti censiti a sistema a determinati gruppi (RUP, DEC, Strutture di supporto);

• gestire specifici permessi nelle operazioni effettuabili nelle varie fasi del ciclo passivo, in modo tale che ogni singolo utente possa operare solo sui contratti a cui è associato.

1.2.8.4.Gestione DURC

Il DURC (Documento Unico di Regolarità Contributiva) è un documento che attesta che siano stati regolarmente versati i contributi INPS, INAIL e casse Edili.

Gli obiettivi della funzionalità sono i seguenti:

• censire i DURC da associare ai fornitori;

• verificare la validità del DURC in fase di pagamento di un fornitore.

1.2.8.5.Gestione Split Payment Passivo

Pertanto, come già detto altrove, il sistema dovrà gestire sia lo split payment attivo che lo split payment passivo. Gli obiettivi della funzionalità sono i seguenti:

• censire appositi codici IVA di tipo split payment passivo;

• gestire registrazioni di fatture e note credito acquisto, facendo in modo che l’importo IVA soggetto

a split payment sia:

o decrementato dall’importo da pagare della fattura (o da rimborsare della nota di credito);

o neutralizzato da un movimento IVA vendita uguale e contrario, nella lista delle transazioni IVA.

1.2.8.6.Gestione Trattenute 0.5%

La gestione delle ritenute di garanzia (o “trattenute 0,5 %”) si rende necessaria per quei contratti che prevedono clausole in base alle quali il committente, all’atto dei pagamenti dovuti all’appaltatore in acconto, o in base a stati di avanzamento lavori, trattiene una determinata percentuale (pari allo 0,5%), al fine di assicurarsi contro possibili problemi o inadempimenti.

Gli obiettivi della funzionalità sono i seguenti:

acquisto che rende completamente fatturato il contratto.

1.2.9. Estrazione ed elaborazione dati per la trasparenza

Lazio Innova si avvale, al momento, di una soluzione proprietaria, denominata Bridge PA 33, come interfaccia per l’estrazione, il controllo e la pubblicazione dei dati in Trasparenza (portale PA33). Lazio Innova, sulla base della proposta ricevuta, comunicherà, in fase di conferma dei requisiti, la scelta definitiva tra continuare ad avvalersi della soluzione in essere o di configurare il Sistema BC per una esportazione diretta verso il portale di pubblicazione dati di trasparenza. Nel primo caso provvederà autonomamente a riconfigurare il tracciato dei dati, oggi in uso, in base alle nuove logiche di Ciclo Passivo che verranno implementate sul Sistema BC (si veda, a questo scopo, anche il successivo §3.7). Nel secondo caso richiede che sul Sistema BC vengano implementate funzioni di estrazioni, controllo e trasmissione, analoghe a quelle attualmente in uso.

1.2.10. Fatture di acquisto/Corrispettivi registrati senza legame con l’ordine

Nell’attuale Sistema NAV, vengono registrate fatture senza riferimento all’accertamento e quindi senza effettivo legame con l’ordine di acquisto. L’utente provvede ad incrementare le quantità ricevute e fatturate sull’ordine mediante apposito tool personalizzato e a rettificare l’impegno budget dell’ordine.

In Business Central, in ottica di snellimento processi, tal processo potrebbe essere gestito mediante il workaround seguente: registrazione fatture di acquisto o corrispettivi senza che ci sia un ordine di acquisto preventivo. In questo modo non sarà necessario procedere a rettifiche sull’ordine. Tuttavia, l’esigenza di Lazio Innova è quella di tracciare tutti gli acquisti mediante RdA/Ordini per cui l’alternativa al workaround sarà procedere ad una personalizzazione analoga a quanto presente attualmente sul Sistema NAV.

1.2.11. Ordini di reso acquisto

Nell’attuale Sistema NAV è presente una personalizzazione legata agli ordini di reso acquisto. In particolare, alla registrazione di spedizioni reso e note di credito acquisto agganciate a queste ultime, è possibile stornare le quantità ricevute e fatturate dell’ordine di acquisto originario agganciato all’ordine di reso. Lo scopo di questa personalizzazione è quello di rilavorare ordini di acquisto a seguito di note di credito ricevute dal fornitore o a seguito di errata imputazione in sede di registrazione fatture di acquisto, aggiornando di conseguenza il tracciato estratto dall’applicativo per la pubblicazione in trasparenza.

1.3. GESTIONE COMMESSE

Lazio Innova richiede l’attivazione, sul Sistema BC, di un modulo di gestione commesse integrato con il modulo per la gestione dei time report (vedi successivi §1.3.5 e §3.4).

1.3.1. Anagrafica commessa

Sulla scheda commessa, nel Sistema BC, dovranno essere integrati i seguenti campi necessari:

a) Servizio: campo in cui gli utenti andranno ad attribuire il valore della dimensione “Servizio”;

b) Dir. Regionale: campo in cui gli utenti andranno ad attribuire il valore della dimensione “Dir. Regionale”;

c) Assessorato: campo che rimanda ad una tabella che riporta una lista di valori;

d) Nr. Commessa raggr.: l’utente sceglierà la commessa di raggruppamento dalla lista di commesse;

e) IVA Indetraibile: campo che, se valorizzato, identificherà l’obbligo di utilizzo di IVA indetraibile per RdA, Ordini, Fatture, Note di credito acquisti (il dettaglio della personalizzazione è rimandato al successivo §1.3.3). Dovrà essere oggetto di valutazione specifica, in fase di conferma dei requisiti, la

NAV:

• Controller;

• Responsabile ufficio;

• Linea di azione;

• Nr. Scheda.

1.3.2. Gestione costi/prezzi in commessa

Le contabilizzazioni in commessa seguono tre logiche differenti in base alla tipologia di task di commessa:

a) Risorse interne – Task 10;

b) Risorse esterne – Task 20;

c) Altri costi – Task 30.

Le contabilizzazioni su Task “Risorse interne” andranno effettuate attraverso la registrazione di scritture

contabili di commessa imputare sulle risorse.

Le contabilizzazioni su Task “Risorse esterne” andranno effettuate attraverso la registrazione di fatture/note di credito imputate su articoli che identifichino le figure professionali via via coinvolte.

Le contabilizzazioni su Task “Altri costi” riguarderanno tutte le registrazioni effettuate o direttamente su

Conto C/G o richiamando articoli “di servizio” in ordini, fatture, note di credito.

Sono state identificate quattro tipologie di trattamento dei costi/prezzi di commessa:

1) Fondo di Dotazione/Struttura:

a. Risorse interne: Le giornate delle risorse interne sono valorizzate esclusivamente sul costo totale, che è calcolato considerando le giornate caricate dalle risorse interne moltiplicate per il costo medio aziendale per figura professionale;

b. Risorse esterne: Il costo contabilizzato relativo alle risorse esterne viene ribaltato per lo stesso importo sul prezzo;

c. Altri costi: Il costo contabilizzato relativo agli altri costi viene ribaltato per lo stesso importo sul prezzo.

2) Altri Fondi/Fondi comunitari:

a. Risorse interne: Le giornate delle risorse interne sono valorizzate sul costo totale, che è calcolato considerando le giornate caricate dalle risorse interne moltiplicate per il costo medio aziendale per figura professionale. Il costo viene ribaltato sul prezzo;

b. Risorse esterne: Il costo contabilizzato relativo alle risorse esterne viene ribaltato per lo stesso importo sul prezzo;

c. Altri costi: Il costo contabilizzato relativo agli altri costi viene ribaltato per lo stesso importo sul prezzo.

3) POR:

a. Risorse interne: Le giornate delle risorse interne sono valorizzate sul costo totale e sul prezzo totale, che sono calcolati considerando le giornate caricate dalle risorse interne moltiplicate per il costo/prezzo medio aziendale per figura professionale;

b. Risorse esterne: L’ammontare del costo totale/prezzo totale è dato dalle giornate fatturate moltiplicate per il costo/prezzo indicato per figura professionale;

c. Altri costi: Il costo contabilizzato relativo agli altri costi viene ribaltato per lo stesso importo sul prezzo.

moltiplicate per il costo/prezzo medio aziendale per figura professionale o particolari tariffe associate direttamente in commessa;

b. Risorse esterne: L’ammontare del costo totale/prezzo totale è dato dalle giornate fatturate moltiplicate per il costo/prezzo indicato per figura professionale o particolari tariffe associate direttamente in commessa;

c. Altri costi: Il costo contabilizzato relativo agli altri costi viene ribaltato per lo stesso importo sul prezzo.

Le logiche presenti nelle quattro tipologie sopra descritte avranno impatti su tutte le registrazioni dalle quali verranno generati movimenti contabili di commessa, ovvero tutte le registrazioni per cui verrà valorizzato dall’utente il campo “Nr. commessa”.

1.3.3. Gestione IVA indetraibile su commessa

Dovrà essere previsto a Sistema un controllo sulla valorizzazione di Categorie articolo/servizio IVA in RdA, Ordini di acquisto, Ordini programmati di acquisto, Ordini di reso acquisto, Fatture di acquisto e Note di credito acquisto. In particolare, dovrà essere obbligatorio da parte dell’utente inserire una Categoria articolo/servizio IVA a cui è associata una % di detraibilità zero in Setup Registrazioni IVA se la commessa inserita in riga preveda IVA indetraibile.

Laddove venga attribuita IVA indetraibile alle righe di documenti passivi (sia per commessa sia per natura del costo) l’impegno di budget associato a documenti passivi dovrà essere sempre comprensivo della quota parte di IVA indetraibile:

• Per le RdA, sin dall’invio in approvazione;

• Per gli ordini di acquisto, al rilascio;

• Per gli ordini programmati di acquisto (laddove sia previsto impegno budget sull’ordine programmato);

• Per gli ordini di reso acquisto (disimpegno all’invio in approvazione/rilascio);

• Per le fatture/note di credito di acquisto (impegno/disimpegno alla registrazione).

1.3.4. Reportistica di commessa

Lazio Innova, con riferimento ai report utilizzati sull’attuale sistema NAV richiede di riprodurre i seguenti, sul

Sistema BC:

1) Estrazione incarichi: rispetto all’attuale report è richiesto, inoltre, di dettagliare le quantità e gli importi per data riferimento budget;

2) Report monitoraggio;

3) Movimenti Cont. Industriale.

1.3.5. Integrazione con modulo di time report

Analogamente a quanto già esistente sull’attuale Sistema NAV, anche sul Sistema BC sarà prevista l’integrazione con un modulo aggiuntivo o soluzione equipollente per la gestione della consuntivazione su commessa delle ore di ciascuna risorsa interna.

1.4. CICLO ATTIVO

Il Ciclo Attivo di Lazio Innova riguarda sostanzialmente la registrazione di fatture e note di credito vendita verso clienti pubblici e privati e la contabilizzazione di incassi.

1.4.2. Fatture e Note di credito vendita

Le fatture e le note di credito vendita vengono preparate direttamente dall’ufficio contabilità e finanza ed inviate al SdI. Lazio innova punta all’utilizzo di un workflow approvativo semplificato (approvatori fissi) sulle fatture e note di credito attive provvisorie, prima di procedere alla registrazione delle stesse.

L’utilizzo della funzionalità standard, in Business Central, di creazione fatture e note di credito a partire da righe di pianificazione di commessa dovrà essere valutata definitivamente in fase di conferma dei requisiti.

1.4.3. Registrazione incassi

Le registrazioni relative agli incassi potranno essere fatte tramite le funzionalità standard di registrazioni di

prima nota contabile con la possibilità di collegare l’incasso ad una o più partite clienti aperte.

1.4.4. Gestione solleciti

La gestione standard dei solleciti consentirà di:

• configurare i diversi termini e livelli di sollecito e i relativi testi predefiniti;

• elaborare in maniera massiva i documenti di sollecito sulla base delle scadenze delle partite clienti;

• inviare al cliente una eMail per ogni sollecito emesso.

1.4.5. Gestione scadenzario clienti

I report e le funzionalità standard messe a disposizione dal sistema consentiranno di monitorare le scadenze clienti ed in particolare:

• elaborare uno scadenziario riepilogativo con importi scaduti e in scadenza (ad esempio nei successivi mesi);

• modificare le date di scadenza dei singoli movimenti contabili clienti.

1.5. CONTABILITÀ CESPITI

Il modulo cespiti permette di gestire l’intero ciclo di vita di un cespite garantendo l’integrazione con il modulo di contabilità generale tramite l’aggancio delle categorie di registrazione cespiti ai conti di immobilizzazione, fondo e spesa ammortamento, ecc.

In particolare, il modulo consente di:

• Gestire la scheda cespite;

• Impostare il piano di ammortamento di un cespite;

• Effettuare scritture di costo di acquisto cespite inserendo il cespite dall’OdA/Fattura;

• Generare le proposte di registrazione degli ammortamenti;

• Gestire le riclassifiche da un cespite ad un altro;

• Registrare la rivalutazione o svalutazione di un cespite;

• Registrare la vendita o la dismissione di cespiti;

• Stampare il libro cespiti.

Oltre all’attivazione del modulo si potranno riportare a sistema i cespiti “in corso” per cui si è ipotizzato di:

• Importare a sistema il costo storico e il fondo ammortamento alla data che sarà definita in fase di conferma dei requisiti.

La migrazione delle “partite cespiti” avrà effetto solo sul modulo cespiti in quanto l’alimentazione del modulo

di contabilità generale verrà effettuata tramite migrazione dei saldi patrimoniali di apertura.

campi della relativa anagrafica cespite.

1.5.2. Gestione impegno budget cespiti

Per quanto riguarda l’impegno e il controllo budget relativi all’acquisto di nuovi cespiti o all’incremento di valore di cespiti già esistenti, si è ipotizzato di gestire delle apposite voci di budget (budget di investimento – su commesse di investimento) associate ai conti di immobilizzazione, in quanto il controllo budget a sistema può essere effettuato, da standard, unicamente sull’intera quota di acquisto del cespite. Gestendo delle apposite voci di spesa per gli ammortamenti sarà invece possibile monitorare a consuntivo l’erosione del budget sui conti di spesa ammortamento.

In alternativa alla gestione sopra descritta, sono stati analizzati alcuni scenari (ciascuno dei quali prevede al suo interno criticità):

a) Suddividere il costo di acquisto del cespite in base al piano di ammortamento previsto per le varie categorie di cespiti, pertanto in fase di ammortamento non è necessario che scatti l’impegno di budget. La criticità emersa in fase di analisi del requisito è la possibile modifica dell’attribuzione della commessa/task al cespite. Dovrà essere consentita la modifica della commessa e del task in anagrafica cespite e gestire un tool che ridistribuisca gli impegni di budget, per le annualità del cespite ancora non ammortizzate;

b) Prevedere l’impegno di budget solo in fase di ammortamento, in base alle quote da ammortizzare. La criticità emersa in fase di analisi è l’assenza di controllo preventivo sugli impegni di budget che potrebbero determinarsi alla registrazione degli ammortamenti (quantomeno per i nuovi cespiti, in quanto per i cespiti già presenti è possibile effettuare una previsione degli ammortamenti e quindi prevederne la quota in fase di stanziamento del budget).

1.6. CONTABILITÀ BANCHE

Le registrazioni relative a incassi e pagamenti movimenteranno l’anagrafica corrente bancario e indirettamente

il relativo conto C/G.

L’implementazione del modulo banche consentirà di disporre di alcune funzionalità e reportistiche standard per la verifica del saldo bancario oltre alla possibilità, a seconda della struttura dell’estratto conto bancario, di gestire il processo di riconciliazione con i movimenti bancari registrati a sistema.

1.7. GESTIONE FILTRI E CAMPI

Lazio Innova è interessata a poter beneficiare, grazie alle funzionalità offerte da Business Central, di una maggiore capacità e piena autonomia nella selezione e gestione di filtri e campi da utilizzarsi anche a livello di singolo utente.

1.8. AGGIORNAMENTI BUSINESS CENTRAL

Lazio Innova intende utilizzare Business Central nella versione SaaS (Software-as-a-Service). Tutti gli aggiornamenti (aggiornamenti mensili + 2 Major Release a cadenza semestrale) rilasciati da parte di Microsoft dovranno essere automaticamente installati nell’applicazione: gli aggiornamenti possono riguardare adeguamenti normativi e l’estensione di funzionalità di Business Central.

partendo da quelle con partite aperte e/o movimentate negli ultimi 2 anni;

• Partite aperte clienti e fornitori: la cui migrazione verrà effettuata a ridosso del Go-Live che sarà definito in fase di pianificazione degli interventi, e che riguarderà le partite aperte alla data di riferimento;

• Commesse: verranno importate le commesse “di trascinamento” ovvero le commesse che hanno validità pluriennale. Da valutare se effettuare l’importazione dei relativi movimenti contabili di commessa di anni precedenti;

• Ordini passivi aperti: la cui migrazione verrà fatta a ridosso del Go-Live, che sarà definito in fase di pianificazione degli interventi, e che riguarderà le partite aperte alla data di riferimento. Verranno assegnati gli articoli in riga corrispondenti alle voci del nuovo Piano dei Conti;

• Saldi patrimoniali di apertura: la cui migrazione verrà effettuata a chiusura del bilancio sul Sistema NAV prevedendo dei tracciati per le scritture di apertura sul nuovo sistema.

• Schede cespiti “aperte”.

Lazio Innova renderà disponibili le scritture di apertura sui conti previsti dalla nuova struttura del Piano dei Conti che sarà implementata sul nuovo sistema. Verranno assegnati i conti in riga in base alle voci del nuovo Piano dei Conti.

Le altre anagrafiche e setup quali ad esempio Piano dei conti, setup IVA, Articoli saranno sottoposti ad analisi e riportati sul nuovo sistema a seguito di condivisione e approvazione.

3. ULTERIORI MODULI E INTERFACCE

Lazio innova ha valutato l’esigenza relativa a moduli e interfacce con sistemi esterni da attivare in fase di implementazione del Sistema BC. Il seguente elenco ha carattere indicativo e dovrà essere confermato in sede di verifica dei requisiti (vedi Capitolato §1.2.1.1.1):

1) Tool intermediario per la fatturazione elettronica;

2) Soluzione BI;

3) Soluzione per gestione simulato/extra contabile e competenze;

4) Soluzione per time report;

5) Soluzione per Import Paghe;

6) Applicativo di budgeting;

7) Applicativo per estrazione ed elaborazione dati trasparenza.

Lazio Innova potrà, inoltre, chiedere di sviluppare ulteriori integrazioni, in fase successiva alla messa in esercizio del Sistema BC, con particolare riferimento ai seguenti temi:

8) Collegamento con GecoWeb;

9) Collegamento con Albo Fornitori;

10) Collegamento con gestione documentale.

accettare o rifiutare i file XML ricevuti:

1) L’utente può rifiutare l’XML ricevuto e generare il file EC che verrà inviato al SdI;

2) L’utente può accettare l’XML ricevuto: in questo caso il file viene trasmesso dal Sistema Josh in una cartella di interscambio con il Sistema NAV in modo che si possa procedere all’acquisizione automatica in tabella di staging fatturazione elettronica passiva. Dalla tabella di staging è possibile procedere alla generazione del documento, che viene registrato attraverso le consuete procedure;

3) Trascorsi 15 giorni dalla ricezione del file XML, quest’ultimo viene inviato dal Sistema Xxxx nella cartella di interscambio con il Sistema NAV per poi procedere come descritto al precedente punto 2.

Con il passaggio a Business Central, Lazio Innova punta, oltre alla gestione della fatturazione elettronica passiva, a poter gestire la fatturazione elettronica attiva, che è comunque di volume minimale.

Lazio Innova richiede una soluzione applicativa interfacciata con il Sistema BC tramite un apposito connettore di cui dovrà essere documentato, in sede di offerta tecnica, lo schema di workflow.

La gestione delle comunicazioni con lo SdI (ricezione/trasmissione file XML di fatture e ricezione/trasmissione di notifiche e metadati) dovrà essere svolta dal tool intermediario o soluzione equipollente. L’integrazione con il Sistema BC permetterà di:

• Lato passivo:

o Ricevere nel Sistema BC le fatture, provenienti dal tool intermediario, in apposita area di

staging;

o Generare le fatture in provvisorio sul Sistema BC;

o Rifiutare le fatture su azione dell’operatore, entro 15 giorni dalla trasmissione, e

trasmettere al tool la notifica di rifiuto, che poi inoltrerà allo SdI;

• Lato attivo:

o Trasmettere i dati delle fatture registrate attraverso il tool, allo SdI;

o Visualizzare le notifiche, restituite da SdI, relative a fatture trasmesse attraverso il tool.

3.1.1. Gestione file XML su Sistema BC

Lazio Innova ha l’esigenza di visualizzare gli allegati contenuti nel file XML e il foglio di stile sia da area di staging, sia da fatture/note di credito provvisorie/definitive, sia dagli ordini di acquisto (mediante schermata che rimandi alle fatture registrate a partire dai relativi accertamenti legati all’ordine).

La logica che verrà seguita sarà quella di memorizzare, in un campo BLOB, il file XML trasmesso dall’intermediario e, da questo, innescare le funzioni di visualizzazione allegati collegati all’XML e il relativo foglio di stile. La visualizzazione allegati/fogli di stile verranno effettuate attraverso Funzioni Azure.

3.2. Soluzione BI

Lazio Innova ha l’esigenza di una soluzione Business Intelligence, preferenzialmente basata su tecnologia Microsoft (MS Power BI), che comprenda un set di report e dashboard di analisi preconfigurate basati sui principali dati di Business Central.

I principali report e cruscotti richiesti sono i seguenti:

• Indicatori di bilancio;

• Analisi dei Ricavi;

• Analisi Riclassifiche;

• Analisi Piano dei conti.

Ognuno di tali report dovrà consentire di analizzare i principali dati di bilancio sfruttando le caratteristiche di interattività e navigabilità di MS Power BI.

Quella che segue è un esempio di dashboard per l’analisi di riclassifiche di conto economico e stato patrimoniale con la possibilità di filtrare su le diverse dimensioni di analisi impostate a sistema (CDC, CDR, Voce di Budget nell’ipotesi effettuata per Lazio Innova).

3.3. Soluzione per gestione simulato/extra-contabile e competenze

Lazio Xxxxxx richiede una soluzione per gestire la possibilità di effettuare scritture contabili senza impatto sulla contabilità generale e sul libro giornale e generare in maniera automatizzata scritture di accantonamento a fatture/note credito da ricevere/emettere, Ratei e Risconti.

• Le scritture extra-contabili possono avere lo scopo di:

o Effettuare simulazioni e verificare l’effetto sul bilancio prima della conferma in contabilità;

o Effettuare registrazioni di assestamento/accantonamento infrannuale che non vengano stampate sul libro giornale;

o I moduli aggiuntivi di cui al precedente §1.1.7 potranno essere utilizzati per effettuare registrazioni extra-contabili nel caso in cui sia attivato anche tale modulo.

• Effettuare registrazioni di riallocazione costi (manuale) senza impatto sulla contabilità.

• Le scritture di accantonamento a fatture/note credito da ricevere/emettere verranno generate a partire da carichi/spedizioni registrati su ordini e ordini di reso acquisto/vendita. Dovrà essere possibile registrare le scritture anche in ambiente Extra-Contabile.

• Le scritture di ratei e risconti saranno generate a partire da Fatture/Note di credito di acquisto/vendita e da prime note registrate in contabilità. Dovrà essere possibile registrare le scritture anche in ambiente Extra-Contabile.

3.6. Interfaccia verso applicativo di budgeting

Lazio Innova richiede che il Sistema BC sia collegato con l’applicativo di budgeting (di cui al precedente §1.2.7) che Lazio Innova provvederà a selezionare e ad acquisire autonomamente tra quelle già dotate di connettore verso Business Central.

Attraverso tale soluzione, Lazio Xxxxxx intende gestire le seguenti attività:

1) Stanziamento Budget;

2) Analisi scostamenti Budget rispetto ai dati presenti in Business Central;

3) Analisi dimensionali su scritture contabili registrate in Business Central.

Sarà prevista, quindi, una interfaccia per l’acquisizione Sistema BC degli stanziamenti budget effettuati nell’applicativo di budgeting e l’invio verso di esso di movimenti impegno budget e contabilizzato in Business Central.

3.7. Interfaccia verso portale trasparenza

Con riferimento a quanto già detto nel precedente §1.2.9 sull’interfaccia verso il portale trasparenza sarà realizzata una revisione dei tracciati utilizzati dall’attuale tool BridgePA33 (analogamente a quanto già presente sull’attuale Sistema NAV) oppure la realizzazione ex novo di una interfaccia diretta tramite web services verso il portale per la comunicazione in Trasparenza degli ordini e ordini programmati (attualmente PA33). Gli sviluppi di tale interfaccia saranno funzionali in base allo scenario di Ciclo passivo selezionato.

3.8. Collegamento con GeCoWeb

GeCoWeb è il sistema per la gestione dei programmi di aiuto attualmente in uso presso Lazio Innova che genera i mandati di pagamento.

La gestione dei bonifici è attualmente centralizzata sul sistema di home banking Uniweb; in Business Central è possibile effettuare l’inserimento manuale dei dati del pagamento ad avvenuto bonifico.

L’interfaccia prevede un flusso bidirezionale:

• Da GeCo a BC per i dati relativi ad anagrafica beneficiari e mandati di pagamento;

• Da BC a GeCo per comunicare i dati (da definire) relativi ad ogni mandato di pagamento.

Sarà messa a disposizione una tabella sul Sistema BC su cui GeCoWeb dovrà scrivere i dati dei mandati di pagamento approvati da acquisire e del relativo beneficiario (è necessario per la fattibilità di quanto descritto che GeCoWeb abbia gli strumenti tecnici a disposizione per poter scrivere su tabelle Business Central). L’acquisizione dei dati verrà lanciata manualmente sul Sistema BC attraverso un’apposita funzione che permetterà di scrivere in una maschera ad hoc i dati acquisiti e l’esito dei controlli sui dati forniti. Da questa maschera l’utente potrà escludere eventuali mandati di pagamento per i quali il bonifico sarà effettuato in un momento successivo; a valle di questi controlli l’utente potrà lanciare una funzione che permetterà la creazione delle distinte fornitori sulla base dei mandati di pagamento marcati come da includere. Dalla distinta fornitori verrà creato il file che contiene i dati dei bonifici da importare nell’home banking.

L’interfaccia da realizzare potrà essere basata su una tabella definita nel Sistema BC in cui riportare i dati delle nuove anagrafiche create, di volta in volta, sulla piattaforma fornitori e le modifiche apportate a quelle esistenti. A questo scopo, la piattaforma fornitori esporrà verso il Sistema BC un campo “Data ultima modifica” o altro indicatore che permetta di prendere in considerazione solo le entità modificate dall’ultima sincronizzazione effettuata. La sincronizzazione tra i due sistemi potrà essere schedulata con frequenza da definire.

3.10. Collegamento con gestione documentale

Lazio Innova è dotata di un sistema di gestione documentale, in corso di evoluzione, che include il Protocollo Elettronico, il Fascicolo Elettronico e una archiviazione ordinaria. Il Fascicolo Elettronico costituisce uno sviluppo autonomo realizzato sulla piattaforma del Protocollo allo scopo di supportare insiemi documentali di particolare rilevanza amministrativa. Tra le altre funzioni, il Fascicolo – che comunque opera appoggiandosi su MS XxxxxXxxxx – a è predisposto per gestire, attraverso un modulo apposito, il trasferimento dei documenti in Conservazione.

L’archiviazione ordinaria di Lazio Innova, tradizionalmente gestita mediante cartelle archivio su file system,

potrà evolvere verso l’utilizzo di MS SharePoint che è in dotazione a ciascun utente aziendale.

Lazio Innova potrà, in base a quanto sopra descritto, richiedere sia di realizzare un collegamento con il Fascicolo (ad esempio per tutti i documenti relativi ad Acquisti e Gare, già identificati e classificati), sia richiedere una configurazione ad hoc nell’ambiente di archiviazione ordinaria da mettere in relazione diretta con il Sistema BC.

Document Metadata

Table of Contents

REQUISITI PER L’IMPLEMENTAZIONE DEL SISTEMA GESTIONALE-CONTABILE MICROSOFT DYNAMICS BUSINESS CENTRAL

Document Metadata