11. CESSIONE DEL CONTRATTO
11.1 Il Fornitore ha il diritto di cedere il presente contratto, in tutto o in parte, a una società affiliata, controllata, collegata o in altro modo riconducibile allo stesso gruppo economico (inclusa una società costituita in altra giurisdizione, ad esempio negli Stati Uniti d'America), previo preavviso scritto di 30 (trenta) giorni al Cliente. Il cessionario assumerà tutti i diritti e obblighi derivanti dal presente contratto, garantendo continuità di servizio, invariabilità delle condizioni economiche, invariabilità della Specifica Tecnica e mantenimento delle medesime garanzie verso il Cliente.
11.1bis Responsabilità solidale del cedente. Per un periodo di 12 (dodici) mesi dalla data effettiva della cessione, il Fornitore originario rimarrà solidalmente responsabile, insieme al cessionario, dell'esecuzione delle obbligazioni contrattuali, a tutela del Cliente.
11.2 Il Cliente non potrà cedere il contratto a terzi senza il consenso scritto del Fornitore, fatta eccezione per operazioni straordinarie (fusione, scissione, acquisizione) che coinvolgano l'intera azienda del Cliente.
13. FASI FUTURE (OPZIONI NON VINCOLANTI)
13.1 Le Parti si danno reciprocamente atto dell'intenzione di valutare congiuntamente, al termine della Fase 1 e sulla base dei risultati operativi conseguiti, l'estensione della collaborazione alle seguenti fasi:
- Fase 2: integrazione del modulo Ordini di Acquisto (OdA), con riconciliazione automatica DDT/OdA a livello di singola riga
- Fase 3: integrazione del modulo Fatture fornitori e hub documentale unificato
13.2 Le Fasi 2 e 3 saranno oggetto di Statement of Work (SOW) separati, formalizzati come addendum al presente contratto, con ambiti, prezzi, tempistiche e condizioni specifiche da definirsi.
13.3 Nulla nel presente articolo costituisce impegno vincolante di alcuna delle Parti a procedere con le Fasi 2 e 3.
14. COMUNICAZIONI
14.1 Tutte le comunicazioni formali dovranno essere trasmesse agli indirizzi sotto indicati:
Fornitore:
- Email per comunicazioni formali: admin@nodeagency.ai
- Indirizzo postale: Joke Smitstraat 11, 5803 AG Venray, Paesi Bassi
- Referente legale (firmatario): Nicolaas Huggers, bestuurder di Huggers Holding B.V.
- Referente operativo: Cristoforo Perrone (admin@nodeagency.ai)
Cliente (Monaco S.p.A.):
- Email per comunicazioni operative: monacospa@monacospa.eu
- PEC per notifiche formali: [da confermare alla firma]
- Indirizzo postale: Via Lucrezio Caro, n. 38 — 00193 Roma (RM), Italia
- Referente commerciale: Federico Monaco (Legale Rappresentante)
- Referente tecnico: Maurizio Di Berardino
15. LEGGE APPLICABILE E FORO COMPETENTE
15.1 Il presente contratto è disciplinato e interpretato secondo la legge olandese, ad esclusione delle norme di diritto internazionale privato e della Convenzione delle Nazioni Unite sulla vendita internazionale di beni (CISG).
15.2 Per ogni controversia derivante o connessa al presente contratto, le Parti riconoscono la competenza esclusiva del Tribunale di Amsterdam (Rechtbank Amsterdam), Paesi Bassi.
15.3 Il presente contratto è redatto in lingua italiana, che farà fede tra le Parti ad ogni effetto.
16. DISPOSIZIONI GENERALI
16.1 Accordo integrale: il presente contratto, unitamente agli Allegati A, B e C, costituisce l'intero accordo tra le Parti sull'oggetto qui regolato e sostituisce ogni precedente accordo, comunicazione o intesa, scritta od orale, incluse le trattative pre-contrattuali.
16.2 Modifiche: ogni modifica o integrazione del presente contratto sarà valida solo se redatta per iscritto e sottoscritta da entrambe le Parti.
16.3 Invalidità parziale: qualora una o più clausole del contratto risultassero invalide, inefficaci o inapplicabili, le restanti clausole rimarranno pienamente valide ed efficaci. Le Parti si impegnano a sostituire la clausola invalida con altra di equivalente effetto economico e giuridico.
16.4 Rapporto tra le Parti: il Fornitore agisce quale soggetto economico indipendente. Nessuna disposizione del presente contratto potrà essere interpretata come costituzione di rapporto di lavoro subordinato, società, joint venture, agenzia o rappresentanza.
16.5 Tolleranza: la mancata o ritardata azione di una Parte a far valere un proprio diritto non costituirà rinuncia allo stesso.
FIRME
Le Parti, dopo lettura e piena comprensione del contratto e dei suoi Allegati, sottoscrivono in segno di accettazione integrale.
Per il Fornitore — Huggers Holding B.V. (Node AI)
Nome e Cognome: Nicolaas Huggers
Qualifica: bestuurder / amministratore
Luogo: Venray, Paesi Bassi
Data: 28 / 04 / 2026
Firma: Nicolaas Huggers
Per il Cliente — Monaco S.p.A.
Nome e Cognome: Federico Monaco
Qualifica: Legale Rappresentante
Luogo: ______________________________________
Data: _____ / _____ / 2026
Firma: ______________________________________
ALLEGATO A — SPECIFICA TECNICA INTEGRAZIONE AS/400
Documento tecnico di riferimento per l'integrazione tra la piattaforma Node AI DDT (cloud) e il sistema IBM i (AS/400). Versione 2.0. Sulla base del confronto tecnico del 15 aprile 2026, il documento si concentra sull'approccio concordato: ODBC su tabella di staging + procedura RPG. Descrive architettura, tracciato record, requisiti tecnici e checklist di verifica. Il presente Allegato è parte integrante e vincolante del Contratto e prevale, in caso di conflitto, sull'eventuale versione pubblicata online.
A.1 Contesto e Ambito dell'Integrazione
Il sistema Node AI acquisisce DDT cartacei, estrae i dati strutturati tramite AI Vision e li presenta all'operatore per validazione umana. Solo i DDT in stato APPROVED sono eligibili per l'invio al gestionale IBM i. Questo documento copre esclusivamente il canale di trasporto tra i due sistemi.
Flusso Funzionale
`` [Scansione DDT] → Node AI / AI Vision → estrazione campi strutturati → Validazione umana (UI operatore, 2° livello di controllo) → DDT in stato APPROVED → Invio a IBM i ← oggetto del presente documento → Acknowledge / risposta / eventuale stato errore ``
Requisiti Funzionali del Canale
- Trasporto header + righe di ogni DDT come unità logica
- Supporto a idempotency (external ID univoco per DDT)
- Acknowledge sincrono o asincrono con stato e motivo errore
- Retry automatico su failure transitori, senza duplicazione
- Audit log completo lato Node AI (payload, timestamp, risposta)
- Supporto a batch o event-driven a seconda dell'opzione scelta
Fuori Ambito
- Lettura anagrafiche fornitori / articoli (da definire in fase successiva, tipicamente via export o lookup API)
- Generazione numero interno DDT (resta lato IBM i)
- Logica di business del gestionale (validazioni IVA, periodi contabili, ecc.)
A.2 Modello Dati e Tracciato Record di Riferimento
Modello dati di riferimento che Node AI inserirà nelle tabelle di staging. Nomenclatura e tipologie sono adattabili alle convenzioni del Cliente. La struttura sotto è indicativa — lo schema definitivo delle tabelle Db2 va concordato con il team IBM i in fase di setup.
``json { "external_id": "ddt_2026_04_16_a7f3b2", "source_document_id": "doc_92f1...", "approved_at": "2026-04-16T10:23:11Z", "approved_by": "operator@cliente.it", "header": { "numero_ddt": "4521/2026", "data_ddt": "2026-04-12", "fornitore_codice": "FORN00128", "fornitore_ragione_sociale": "Edilizia Rossi S.r.l.", "fornitore_piva": "01234567890", "causale": "C01", "note": "" }, "righe": [ { "numero_riga": 1, "articolo_codice": "ART00451", "descrizione": "Cemento Portland 325", "quantita": 50, "unita_misura": "QL", "numero_ordine_acquisto": "OA-2026-0892", "prezzo_unitario": null, "confidence": 0.98 } ], "attachments": [ { "type": "source_pdf", "url": "https://...", "sha256": "..." } ] } ``
Campi obbligatori (header): external_id, numero_ddt, data_ddt, fornitore_piva, fornitore_ragione_sociale.
Campi obbligatori (riga): numero_riga, descrizione, quantita, unita_misura.
Campo opzionale (riga): numero_ordine_acquisto — non tutti i DDT cartacei riportano il numero d'ordine, pertanto il campo è opzionale per riga. Quando presente, abilita la chiusura automatica degli OdA lato IBM i.
Note sul modello: tutti i campi testuali sono UTF-8; le date in ISO 8601; i codici fornitore/articolo sono placeholder — la strategia di mapping (lookup da anagrafica IBM i, import CSV periodico, o invio di codice grezzo con risoluzione lato IBM i) sarà definita in fase di setup.
A.3 ODBC su Tabella di Staging + Procedura RPG
Node AI scrive i DDT validati su una o più tabelle di staging dedicate in Db2 for i via connessione ODBC. Una procedura RPG/CL runtime lato IBM i monitora la staging table in loop, consuma i record, valida e li inserisce nelle tabelle definitive del gestionale con la propria logica di business. Pattern sicuro e consolidato negli ambienti IBM i.
> Nota. Questo pattern è diverso dalla scrittura diretta nelle tabelle del gestionale, che non è raccomandata in quanto bypasserebbe trigger, validazioni e logica RPG. Qui Node AI scrive solo sulla staging table; la procedura RPG del team IBM i fa il resto, con pieno controllo.
Architettura
- Protocollo: SQL
INSERT over DRDA / DDM via ODBC, connessione TCP diretta a Db2 for i. - Node AI → ODBC →
INSERT su tabelle NODEAI_DDT_H (testata) e NODEAI_DDT_R (righe) → colonna STATUS = 'NEW'. - Procedura RPG (runtime / loop) →
SELECT WHERE STATUS = 'NEW' → valida → scrive nelle tabelle definitive del gestionale → aggiorna STATUS = 'POSTED' o 'ERROR' con messaggio.
Tabelle di staging (schema dedicato, es. NODEAI)
NODEAI_DDT_H — testata: external_id (PK), p_iva, ragione_sociale, data_ddt, numero_ddt, causale, note, status, error_msg, created_at, posted_atNODEAI_DDT_R — righe: external_id (FK), numero_riga, articolo_codice, descrizione, quantita, unita_misura, numero_ordine_acquisto, prezzo_unitario
Componenti tecnici
- Lato Client: IBM i Access Client Solutions (ACS) ODBC Driver · JTOpen / JT400 (JDBC, open source) · da Node.js: pacchetto npm
odbc o bridge Java via JT400 - Porte: 446 (DRDA) · 8471 (IBM i Access) · variabili a seconda del driver e di TLS on/off
- Autenticazione: user profile IBM i dedicato con
GRANT minimi (INSERT + SELECT + UPDATE solo su schema NODEAI); nessun accesso alle tabelle del gestionale; password complessa o Kerberos EIM - Transazioni: commitment control (
CHG / ALL) con COMMIT/ROLLBACK; header + righe inserite come UOW atomica - Idempotency:
external_id come PRIMARY KEY sulla staging table; un secondo INSERT con lo stesso id fallisce con constraint violation → Node AI tratta come successo già avvenuto - Feedback: Node AI può fare
SELECT status, error_msg FROM NODEAI_DDT_H WHERE external_id = ? per verificare l'esito; alternativa: callback HTTP dal consumer RPG verso Node AI - Encoding: Db2 for i usa CCSID (es. 37 / 1144 per EBCDIC italiano); il driver ODBC converte UTF-8 ↔ CCSID lato client; verificare mapping per caratteri accentati (à, è, ò)
- Rete: porta Db2 esposta via VPN IPSec / WireGuard (mai su internet pubblica); alternativa: tunnel SSH
- Journaling: le staging tables devono essere journaled per supportare commitment control, audit e recovery
Vantaggi del pattern
- Sicuro: Node AI non tocca le tabelle del gestionale; il consumer RPG mantiene il pieno controllo
- Near-real-time: la procedura RPG in loop processa i record in pochi secondi
- Setup lato Node AI semplice (connessione ODBC + INSERT SQL)
- Compatibile con qualsiasi versione di IBM i (non richiede IWS o MQ)
- Feedback loop nativo via campo
status - Il team IBM i lavora interamente nel proprio ecosistema (RPG, SQL, CL)
- Chiusura OdA automatica tramite
numero_ordine_acquisto per riga
Svantaggi / Aspetti da gestire
- Richiede creazione delle staging tables e della procedura RPG consumer (effort lato team IBM i del Cliente)
- Connessione VPN tra cloud Node AI e IBM i on-premise
- Pattern polling-based: senza callback, Node AI deve interrogare lo status
Da verificare in setup
- Driver ODBC IBM i Access disponibile (licenza 5770-XE1)
- Disponibilità del team RPG per lo sviluppo del consumer
- Topologia di rete: VPN già in uso o da configurare
- Schema staging: conferma nomi tabelle, campi e tipi con il team IBM i
- Frequenza di polling del consumer (loop continuo vs schedulato)
- Retention dei record processed nella staging table
A.4 Informazioni Richieste al Team Tecnico del Cliente
Da raccogliere prima o durante il kickoff tecnico per restringere la spec di dettaglio.
Ambiente IBM i
- Versione corrente (V7R3 / V7R4 / 7.5)
- Deployment: on-premise / IBM Cloud / Power Virtual Server
- ERP / gestionale installato (custom RPG, Gestionale 1, Diapason, AS/Sistemi, J Galileo, Infor, altro)
- Team interno RPG/COBOL o software house esterna
- Disponibilità di ambienti separati dev / test / prod
Funzionalità esistenti
- Driver ODBC IBM i Access disponibile? Licenza 5770-XE1?
- Connessioni ODBC/JDBC già in uso da sistemi esterni?
Rete e sicurezza
- Topologia: IBM i in DMZ, LAN interna, accessibile via VPN
- VPN già in uso o da configurare per ODBC
- Policy su certificati TLS (CA interna o pubblica)
- Firewall rules esistenti
- Requisiti GDPR / compliance specifici
Contratto dati
- Schema tabella DDT (header + righe): nomi campi, tipi, lunghezze, mandatory
- Strategia master data (fornitori, articoli): lookup API, export CSV, mapping lato Cliente
- Encoding atteso (UTF-8 vs CCSID)
- Numerazione documento: ID interno o external reference
- Idempotency: esiste un campo
external_id univoco? - Validation rules server-side (cosa causa reject)
- Transazionalità: header + righe atomiche?
Operatività
- Volumi medi e di picco (DDT/giorno)
- Latenza accettabile (real-time vs batch)
- Meccanismo di error notification preferito
- SLA e finestre di manutenzione
- Monitoring / alerting esistenti integrabili
A.5 Requisiti Trasversali
Idempotenza
Ogni DDT ha un external_id univoco generato da Node AI (UUID). IBM i deve usarlo come chiave di deduplicazione: un secondo invio con lo stesso id è no-op (non crea duplicato, risponde con lo stato del precedente).
Retry automatico
Node AI implementa retry con backoff esponenziale su errori transitori (5xx, timeout, errori di rete). Massimo 5 tentativi in 24 ore. Dopo il fallimento definitivo, il DDT torna in stato TRANSFER_ERROR lato Node AI per revisione manuale.
Atomicità transazionale
Header DDT + righe sono un'unica unità transazionale. Nessun caso di header salvato con righe mancanti. COMMIT/ROLLBACK sulla staging table garantiscono atomicità.
Tracciabilità
Node AI mantiene log completo di ogni tentativo di invio: payload, timestamp, risposta, esito, operatore approvatore. Ritenzione: 12 mesi (configurabile). Esportabile su richiesta del Cliente.
Monitoraggio
Metriche disponibili lato Node AI: throughput, latenza, tasso errori, conteggio retry, profondità coda. Alert proattivi su anomalie. Dashboard di stato accessibile al Cliente.
Sicurezza
- TLS 1.2+ su tutti i canali
- Credenziali in secret manager, mai in codice o log
- User profile IBM i con privilegi minimi
- IP whitelisting lato IBM i ove applicabile
- Rotazione credenziali ogni 90 giorni
Separazione ambienti
Prima del go-live in produzione, l'integrazione deve essere testata end-to-end su ambiente non-prod (LPAR o libreria dedicata lato IBM i, tenant dedicato lato Node AI). In assenza di ambiente non-prod IBM i, le Parti concorderanno una finestra di test controllata in produzione con piano di rollback.
A.6 Criteri di Accettazione del Go-Live
Ai fini dell'art. 3.5 e dell'art. 6 del Contratto, la Soluzione si considera conforme alle specifiche quando, durante un periodo continuativo di test di 5 (cinque) giorni lavorativi in ambiente di produzione (o, se non disponibile, in ambiente di collaudo concordato), siano soddisfatti tutti i seguenti criteri quantitativi:
| # | Criterio | Soglia di accettazione |
|---|
| AC.1 | Accuratezza estrazione header (campi obbligatori: numero DDT, data, P.IVA, ragione sociale fornitore) su un campione di 100 DDT reali | ≥ 95% di campi correttamente estratti, misurato post-validazione operatore |
| AC.2 | Accuratezza estrazione righe (descrizione articolo, quantità, unità di misura) sullo stesso campione | ≥ 90% di righe correttamente estratte |
| AC.3 | Scrittura ODBC su staging table | 0 errori di scrittura su 100 DDT approvati nel periodo di test |
| AC.4 | Idempotenza | un secondo invio dello stesso external_id non crea record duplicati e ritorna lo stato del precedente |
| AC.5 | Disponibilità della Soluzione (uptime) | ≥ 99,0% nelle ore lavorative del periodo di test |
In caso di mancato superamento di uno o più criteri, il Fornitore disporrà di 14 (quattordici) giorni dalla rilevazione scritta per sanare la non conformità prima che il Cliente possa attivare la garanzia di soddisfazione di cui all'art. 6.
ALLEGATO B — ACCORDO SUL TRATTAMENTO DEI DATI (DPA)
Accordo ai sensi dell'art. 28 Regolamento (UE) 2016/679 ("GDPR").
B.1 Ruoli
- Titolare del trattamento: Monaco S.p.A.
- Responsabile del trattamento: Huggers Holding B.V.
B.2 Oggetto e finalità
Il Responsabile tratta dati personali per conto del Titolare al solo scopo di eseguire i servizi previsti dal contratto principale (digitalizzazione DDT e integrazione AS/400).
B.3 Categorie di interessati
- Dipendenti, referenti o contatti commerciali dei fornitori del Titolare, eventualmente indicati nei DDT
- Personale del Titolare autorizzato ad utilizzare la Soluzione
B.4 Categorie di dati personali
- Dati anagrafici (nome, cognome) di referenti presso fornitori
- Dati di contatto commerciale (email, telefono) — se presenti in DDT
- Dati fiscali/identificativi dei fornitori (P.IVA, CF, ragione sociale, indirizzi)
- Dati di autenticazione e log di accesso degli utenti della Soluzione
B.5 Durata del trattamento
Per l'intera durata del contratto principale. Alla cessazione, cancellazione o restituzione dei dati entro 30 giorni su richiesta scritta del Titolare, con conferma scritta entro 60 giorni.
B.6 Obblighi del Responsabile
Il Responsabile si impegna a:
- trattare i dati esclusivamente su istruzione documentata del Titolare
- garantire la riservatezza del personale autorizzato al trattamento
- adottare misure tecniche e organizzative adeguate ex art. 32 GDPR (crittografia in transito TLS 1.3 e a riposo AES-256, controllo accessi basato su ruoli, logging, backup cifrati)
- assistere il Titolare nell'evasione delle richieste degli interessati (artt. 15-22 GDPR)
- notificare al Titolare eventuali data breach senza ingiustificato ritardo e comunque entro 48 (quarantotto) ore lavorative dalla conoscenza, fornendo le informazioni di cui all'art. 33 GDPR per consentire al Titolare di adempiere ai propri obblighi di notifica
- non avvalersi di sub-responsabili diversi da quelli autorizzati in B.7 senza previa autorizzazione scritta del Titolare
B.7 Sub-responsabili autorizzati (alla firma)
| Sub-responsabile | Sede | Finalità | Garanzie trasferimento |
|---|
| Vercel Inc. | USA | Hosting applicazione web | SCCs UE 2021/914 |
| Supabase Inc. | USA | Database PostgreSQL + object storage | SCCs UE 2021/914 |
| Anthropic PBC | USA | Elaborazione AI/OCR dei DDT (modelli Claude) | SCCs UE 2021/914 + misure supplementari |
Eventuali variazioni di sub-responsabili saranno comunicate al Titolare con preavviso scritto di 30 giorni, durante i quali il Titolare potrà sollevare obiezioni motivate; in caso di obiezione fondata e non superabile, ciascuna Parte potrà recedere dal contratto senza penalità con effetto al termine del preavviso.
B.8 Trasferimenti extra-UE
I trasferimenti di dati personali verso Paesi terzi (in particolare USA) sono effettuati sulla base delle Standard Contractual Clauses (SCCs) approvate dalla Commissione Europea con Decisione 2021/914, integrate da misure supplementari ove necessario (pseudonimizzazione, crittografia end-to-end, minimizzazione).
B.9 Diritto di audit
Il Titolare può richiedere, con preavviso scritto di almeno 30 giorni e non più di una volta l'anno (salvo in caso di data breach accertato), documentazione probante il rispetto del presente DPA (es. certificazioni, report ISO 27001, penetration test).
B.10 Cessazione
Alla cessazione del contratto principale, il Responsabile, a scelta del Titolare, restituirà o cancellerà tutti i dati personali trattati, fornendo attestazione scritta della cancellazione entro 60 giorni.
ALLEGATO C — CHECKLIST DI ONBOARDING TECNICO
Al fine di avviare regolarmente la Fase 1, il Cliente si impegna a fornire al Fornitore, entro 10 giorni lavorativi dalla firma, quanto segue:
| # | Elemento | Responsabile Cliente | Status |
|---|
| 1 | Credenziali ODBC di lettura/scrittura verso ambiente IBM i di collaudo | Maurizio Di Berardino | [ ] |
| 2 | Credenziali ODBC di lettura/scrittura verso ambiente IBM i di produzione | Maurizio Di Berardino | [ ] |
| 3 | Tracciato record del gestionale attuale (se esistente) | Team IT | [ ] |
| 4 | Anagrafica fornitori attivi con P.IVA, CF, ragione sociale (export CSV) | Team IT / Amministrazione | [ ] |
| 5 | 20 DDT campione (PDF/scansioni reali) per calibrazione OCR | Amministrazione | [ ] |
| 6 | Accesso in lettura alla cartella SharePoint DDT | Team IT | [ ] |
| 7 | Dettagli rete e VPN (se richiesti per accesso ambiente) | Team IT | [ ] |
| 8 | Designazione referente tecnico (in orario d'ufficio) per la fase di integrazione | Maurizio Di Berardino | [ ] |
| 9 | Sessione kickoff da programmare (call 60 minuti) | Federico Monaco + tecnici | [ ] |
Fine del documento.