Il journal name governa il dato prima che venga scritto
In Dynamics 365 Finance quasi tutto il dato contabile entra da un journal, e l’oggetto che ne governa il comportamento è il journal name, non la singola riga. Sul journal name si definiscono il tipo di journal (che ne determina l’uso: daily, payment, invoice register, fixed assets, eliminations), la number sequence del voucher, il default di offset account e di valuta, il posting layer proposto e l’eventuale workflow di approvazione. Nel disegno di una soluzione la domanda tipica non è “come creo un journal” ma “quanti journal name mi servono”: ne serve uno per ogni insieme distinto di regole di controllo, perché le restrizioni sono attributi del name, non della legal entity.
Il general journal resta lo strumento generico per scritture manuali e rettifiche. I journal specializzati esistono perché portano con sé la logica del sottosistema — settlement, ammortamento, ritenute — che una scrittura libera in general journal non replicherebbe: se lo scenario parla di pagamenti fornitore o di transazioni su un asset book, la risposta è il journal dedicato, non il general journal con offset manuale.
Journal control e separazione dei ruoli
Il journal control è la funzione che limita, per quel solo journal name, quali legal entity, quali tipi di conto, quali main account e quali valori di segmento delle financial dimension sono utilizzabili. È il criterio di scelta che l’esame verifica: quando il requisito è “gli utenti di quel journal non devono poter usare i conti di magazzino”, la risposta è journal control, perché l’account structure agisce su tutta la legal entity e vieterebbe quelle combinazioni anche dove sono legittime. Account structure e advanced rules decidono quali combinazioni main account + dimension sono valide in assoluto; il journal control restringe ulteriormente un singolo canale di inserimento.
La separazione fra chi inserisce e chi registra si ottiene ancora sul journal name, tramite le posting restriction (rendere il journal privato all’utente o a un user group), i limiti di importo per riga o per journal associati ai gruppi di utenti, e il workflow di approvazione. La segregation of duties definita nella sicurezza è un livello diverso: agisce su privilegi e ruoli, non sul singolo journal name.
Posting profile e posting layer
Il posting profile è il ponte fra la transazione del sottosistema e i conti di general ledger: dice quali main account usare per il saldo cliente o fornitore, per gli acconti, per gli interessi, per il valore e l’ammortamento di un cespite. Si configura per gruppo, per singolo record o come default “All”, e la regola di risoluzione va dal più specifico al più generico. Non confonderlo con la posting definition, che genera scritture da regole applicate ai documenti in scenari abilitati appositamente, né con l’account structure, che valida la combinazione ma non sceglie il conto.
Il posting layer consente di tenere separate registrazioni che convivono nello stesso ledger e nello stesso fiscal calendar: le operazioni correnti su un layer, le rettifiche fiscali o di revisione su layer distinti. I financial report e il trial balance si possono produrre per singolo layer o cumulati, quindi non serve né una legal entity separata né una financial dimension dedicata per isolare le rettifiche. Il posting layer di default si imposta sul journal name e può essere modificato sul journal prima della registrazione.
Alcune capacità di questa area arrivano come feature da abilitare nel workspace Feature management: se uno scenario richiede un comportamento che nell’ambiente non compare, la verifica corretta è lì, tenendo presente che certe feature, una volta abilitate, non si disattivano.
Lo storno è l’unica correzione ammessa
Il punto che l’esame verifica con più insistenza: una transazione registrata non si modifica e non si cancella. Si storna, e lo storno genera un nuovo voucher collegato all’originale, con data di storno scelta dall’operatore, così che la pista di controllo resti intatta. Nei sottosistemi vale lo stesso principio con strumenti diversi — la nota di credito per una fattura, il cancel su una transazione di cespite, il reverse settlement per un abbinamento errato — ma la logica è identica: si aggiunge una scrittura contraria, non si riscrive la storia.
Trappole tipiche d’esame
- Vietare certi conti solo agli utenti di un journal → journal control sul journal name: l’account structure vale per l’intera legal entity e bloccherebbe le stesse combinazioni anche dove sono corrette.
- Chi inserisce non deve registrare → posting restriction e workflow sul journal name: la segregation of duties nella sicurezza separa i privilegi, ma non impedisce a un utente di registrare il journal che ha appena creato.
- Isolare le rettifiche di revisione dai saldi correnti → posting layer: creare una legal entity o una financial dimension dedicata è la distrazione classica; il ledger resta uno solo e i report si filtrano per layer.
- Correggere una registrazione sbagliata → storno collegato all’originale: modificare o eliminare il voucher non è un’opzione valida, e “cancellare il journal” funziona solo finché non è registrato.
- Determinare i conti GL di una transazione cliente o fornitore → posting profile: l’account structure valida la combinazione ma non la sceglie, e la posting definition appartiene a un altro scenario.
- Funzionalità descritta ma assente nell’ambiente → Feature management: prima di progettare un workaround, verificare se la feature va abilitata, ricordando che alcune abilitazioni sono irreversibili.