Sappiamo tutti che quando cerchiamo di registrare una fattura di vendita o acquisto e capita un qualsiasi errore, Business Central stacca il protocollo e non ci permette più di eliminare il documento finché non lo registriamo.
Mentre questo comportamento può essere accettabile in un qualsiasi paese preso a caso sul mappamondo, in Italia costituisce un problema assai fastidioso, perché come sappiamo, qui (in realtà non solo qui, ma concedetemi un po' di vis polemica), non si può registrare la fattura numero 1 con data di oggi e la fattura numero 2 con data di ieri; detto in sintesi: il protocollo deve seguire la data.
Giusto come divagazione, quando mi trovavo in USA a seguire un progetto, mi imbattei in facce a dir poco stranite quando iniziai a fare domande circostanziate sui numeri di protocollo delle fatture che gli americani (giustamente) non capivano nemmeno. Si saranno domandati se ero un paranoico oppure un pazzo. Ora non voglio certo mettermi a disquisire in questa sede se sia corretto o meno che una normativa imponga questa sequenzialità tra numeri e date, ma voglio limitarmi a raccontare come mai Business Central ha questo comportamento anomalo e, soprattutto, come potete aggirarlo.
L'anomalia
Per riprodurla dobbiamo fare in modo che venga generato un errore durante la registrazione. Fate quindi questa prova banale: aprite la tabella Setup Registrazioni COGE e cancellate il contenuto del campo Conto vendite in corrispondenza dell'incrocio NAZIONALE-DETTAGLIO, come in figura qui sotto:

A questo punto create un ordine di vendita su un cliente a caso (purché abbia categoria NAZIONALE) e sulle righe mettete uno degli articoli presenti (sono tutti con categoria DETTAGLIO, quindi uno vale l'altro)

Adesso premete il fatidico tasto F9, selezionate Spedizione e fattura e premete OK. Otterrete come risultato un messaggio di errore che vi dice in sostanza che non si può contabilizzare la fattura perché non è stato specificato il conto di ricavo nel setup delle registrazioni (se avete osservazioni sulla qualità del messaggio di errore, leggete il mio post sull'uso dell'istruzione TESTFIELD).

Fin qui tutto giusto. Se però adesso cercate di eliminare l'ordine, noterete un messaggio che vi avverte che, essendo già stato staccato il protocollo, non si può più eliminare il documento.

Questo è uno scenario, ma naturalmente il fastidio non deriva tanto dall'impossibilità di eliminare l'ordine, operazione tutto sommato rara, quanto dall'impossibilità di registrare ulteriori documenti nelle giornate successive finché questo documento non viene contabilizzato, pena il non rispetto della sequenzialità numero-data descritta prima.
L'aspetto tecnico
A questo punto vale la pena spiegare la questione da un punto di vista tecnico, partendo anche da un dato storico.
La procedura di contabilizzazione di una fattura attiva è contenuta nella Codeunit 80 - "Sales-Post". Se la si apre, si scopre che esistono al suo interno ben sei istruzioni di Commit. Semplificando un po', la procedura prima stacca il protocollo da assegnare alla fattura, poi chiude la transazione con un'istruzione di Commit e poi prosegue con il processo di registrazione.
La domanda è: perché chiudere la transazione subito e non aspettare la fine della registrazione?
Il motivo deriva dal fatto che nella versione W1 di Business Central tutti i numeri progressivi (clienti, fornitori, ordini, protocolli delle fatture, ecc) sono contenuti in una tabella sola, la No. Series Line, che viene quindi bloccata non solo quando un utente registra una fattura, ma anche ogni volta che si crea un qualsiasi documento di vendita o acquisto, oppure si inserisce un cliente, un fornitore o un contatto.
Insomma: contenendo tutti i numeratori progressivi delle anagrafiche e dei documenti, se la si tenesse bloccata durante un processo di registrazione, che dura decisamente di più della creazione di un documento o di un cliente, l'intera azienda rimarrebbe praticamente bloccata finché la contabilizzazione non è terminata.
A questo aggiungete il fatto che in passato il vecchio Navision non girava su SQL, che gestisce i blocchi a livello di record, ma su un database proprietario che aveva solo il blocco a livello di tabella, e il gioco è fatto.
La localizzazione italiana passata
Durante la localizzazione, il problema dello stacco preventivo del protocollo venne affrontato con i colleghi, che ci esclusero a priori di commentare le istruzioni di Commit, in quanto questo avrebbe causato troppi blocchi nel database.
La soluzione fu quindi doppia: da un lato creare due tabelle aggiuntive, la No. Series Line Sales per i protocolli delle fatture attive e la No. Series Line Purchase per quelli delle fatture passive e successivamente commentare le Commit delle codeunit 80 e 90. Questo avrebbe garantito un blocco di due tabelle preposte unicamente alla gestione dei protocolli di vendita e acquisto e dunque li avrebbe limitati a questi casi.
Qui sotto trovate l'immagine del setup italiano dei protocolli, che attraverso il campo Tipo di numerazione prevede di specificare se il numeratore è normale (anagrafiche e documenti) oppure un protocollo IVA di acquisto o di vendita.

A seconda di quello che inserite in quel campo, il numeratore finisce proprio in una delle tabelle italiane, oppure in quella standard.
La situazione attuale e la novità
Fino a una certa versione di NAV, le istruzioni di Commit sono rimaste così commentate. Da un certo momento in avanti e per ragioni che non conosco, non occupandomi più della localizzazione del prodotto, sono tornate. Moltissimi partner infatti, come prima cosa, le commentavano, riportando così la versione nuova alla situazione passata.
La brutta notizia è che in AL non è più possibile in alcun modo commentare una riga di codice in una codeunit standard.
Quella buona è l'introduzione nella codeunit 80 di una variabile booleana SuppressCommit, che condiziona proprio l'esecuzione delle istruzioni di Commit presenti

Tale variabile booleana viene impostata dalla procedura globale SetSuppressCommit

che può quindi venire chiamata prima di richiamare la codeunit stessa.
Quindi adesso abbiamo la possibilità di tornare al vecchio comportamento, ovvero una transazione unica che fa anche il rollback dello stacco del protocollo in caso di errore.
PS: per la verità, volendo essere precisi, non tutte le commit andrebbero commentate. Durante alcuni test su un cliente abbastanza grosso, avevo capito che andavano commentate tutte tranne l'ultima, quella che scatta comunque alla fine del processo, pena un pesante abbassamento delle prestazioni. Ma questo comportamento non l'ho comunque mai più testato da altri clienti, limitandomi a non commentarla comunque più.
Comments