Due mondi, un criterio di scelta

Nelle finance and operations apps il reporting si divide in due famiglie che l’esame tiene separate. SSRS produce i documenti dell’application: fatture, packing slip, conferme d’ordine, report operativi interni. L’Electronic reporting (ER) produce i file destinati a un ente esterno o a un partner: dichiarazioni fiscali, file di pagamento bancari, fatturazione elettronica, tracciati di intercambio.

Il criterio da applicare è uno solo: chi detta il formato e quanto spesso cambia. Se il formato è imposto da una norma, da un’autorità fiscale o da un partner esterno ed è soggetto a revisioni, la risposta è Electronic reporting, perché è configurazione e non codice: un adeguamento normativo si distribuisce importando una nuova versione di configurazione, senza build e senza deployable package. Se invece è un documento dell’application, con layout stabile, la risposta è SSRS e si lavora in Visual Studio con gli strumenti per finance and operations.

SSRS: elementi AOT, sviluppo e print management

Un report SSRS è fatto di elementi AOT che vivono nel progetto Visual Studio e viaggiano nel deployable package con il resto del modello: la classe data provider (materializza i dati, spesso in una tabella temporanea quando il volume o la logica lo richiedono), la classe data contract che dichiara i parametri, la classe controller che orchestra dialogo e stampa, il report con i suoi dataset e i suoi design, e il menu item di tipo Output che lo espone all’utente. La query può essere un elemento AOT referenziato dal data provider, oppure i dati possono essere costruiti in X++.

Anche qui vale la regola generale: extension, non overlayering. Si possono aggiungere elementi senza toccare il modello Microsoft, ma quando la modifica riguarda un design standard la strada supportata è in genere duplicare il report nel proprio modello e ripuntare il menu item che lo invoca. Per i documenti stampabili il ripuntamento corretto non è riscrivere la logica standard ma il Print management: la configurazione decide quale report e quale design usare per tipo di documento e per record, ed è estendibile con event handler o Chain of Command sulle classi coinvolte.

Electronic reporting: configurazione, non codice

ER separa i dati dal formato. Il data model descrive il dominio in modo astratto; il model mapping lo collega alle sorgenti reali (tabelle, data entity, metodi); il format definisce il file di output (XML, testo posizionale o delimitato, Excel e Word via template, PDF); il format mapping alimenta il format a partire dal modello. È questa separazione che permette a una modifica di legge di toccare solo il format, lasciando intatto il mapping.

Il ciclo di vita fa parte dello strumento: le configurazioni sono versionate, hanno stati (bozza, completata, condivisa) e si importano dal repository di un provider — tipicamente Microsoft — per essere poi personalizzate come configurazioni derivate. Il punto chiave è proprio questo: si deriva, non si modifica la base, così le versioni successive rilasciate dal provider restano assorbibili. Le destinazioni dell’output (file, e-mail, archiviazione, stampante) si impostano per configurazione senza scrivere codice, e le esecuzioni possono girare in batch.

Trappole tipiche d’esame

  • Il file di pagamento verso la banca cambia tracciato periodicamente → Electronic reporting: un formato imposto dall’esterno e soggetto a revisioni non si scrive in X++; si aggiorna importando una nuova versione di configurazione, senza rilascio di codice.
  • Aggiungere un campo alla fattura cliente stampata → SSRS con Print management: è un documento dell’application; si interviene sul report e si ripunta con il Print management, non riscrivendo la logica standard né spostando il documento in ER.
  • “Personalizza il report standard” → mai overlayering: vale anche per il reporting; dove l’extension non copre la modifica di un design esistente si duplica il report nel proprio modello, senza alterare l’elemento Microsoft.
  • Adattare all’azienda una configurazione ER rilasciata da Microsoft → configurazione derivata: derivare mantiene la possibilità di ereditare le versioni successive del provider; editare la base rompe l’aggiornabilità.
  • Report su volumi grandi che non deve bloccare l’utente → batch framework: l’esecuzione pianificata, con un data provider che pre-elabora i dati, è la risposta attesa; non l’ottimizzazione del design o l’aumento del timeout.
  • Esportazione ricorrente di dati verso un altro sistema → non è reporting: se il tema è l’integrazione (import/export ricorrenti, OData, Batch OData API) la risposta sta nel Data management framework e nelle data entity; ER si sceglie quando il vincolo è il formato imposto dall’esterno, non il trasporto.