E’ stata introdotta nella versione 2009 la possibilità di disabilitare le giacenze negative di magazzino?
Ovvero è possibile impedire ad un operatore di vendere un articolo mandando la sua giacenza in negativo?
Ciao non credo che esista la possibilità di bloccare nella 2009. La possibilità di andare in negativo è necessaria in quanto non sempre l’ufficio acquisti è più veloce dell’ufficio spedizioni a registrare le cose in NAV; impedire l’emissione di una bolla solo perché agli acquisti qualcuno non ha ancora registrato il carico mi parrebbe una cosa fastidiosa (se qualcuno è ammalato che si fa, si aspetta che guarisca?).
In ogni caso puoi sempre introdurla tu come controllo nella codeunit 21.
Ciao
Marco
Ciao Marco,
si è vero che la giacenza negativa può essere utile ma in alcune aziende non vogliono proprio sentire parlare della possibilità di mandare il magazzino in negativo. Poi non sempre la divisione dei compiti è così netta.
In qualsiasi caso avevo già provveduto ad inserire nella CU22 la modifica sfruttando la parte in cui esegue il controllo per gli ordini di trasferimento. L’unica cosa che non mi piace di questa soluzione è il fato che se l’operatore tenta di evadere l’ordine Nav “prenota” il numero di fattura e spedizione…
Ciao
Le commit nei posting, che fan prenotare il codice definitivo, è una delle prime cose che tolgo quando adottiamo una nuova release di Navision.
Questo fondamentalmente perchè quella logica standard nav è una sciocchezza. E con buona pace delle osservazioni sulla transazione più lunga e quindi più bloccante 
Ciao,
Matteo
Mhh…si direi che il tuo suggerimento è da prenderein considerazione…
Ciao, il controllo lo metterei nella codeunit 21, non nella 22. Le commit nella codeunit 80 e 90 vanno commentate, come ha giustamente detto Matteo. Rimane da capire perché le abbiano reintrodotte, visto che nelle versioni precedenti (leggi: molto precedenti) erano commentate. Peraltro il problema della loro introduzione derivava dal blocco che, durante la transazione, veniva posto sulle tabelle delle numerazioni, tabella utilizzata da tutti i granuli di NAV. Per ovviare al problema, nella localizzazione della 2.5 (quindi si parla della preistoria), i danesi stessi ci fecero introdurre delle tabelle ad-hoc per la numerazione dei protocolli (la 12145 e la 12146) che a quel punto potevano rimanere bloccate durante la transazione in quanto comunque divise dalla tabella della numerazione standard (anagrafiche, documenti ecc…). Quindi non ho mai capito per quale motivo le commit siano state reintrodotte, pur mantenendo le tabelle aggiuntive.
Marco
Riguardo i commenti alle commit, l’unica che non va commentata è l’ultima che si trova in fondo alle codeunit.
Marco
Ciao Marco,
perchè nella 21 e non nella 22? Voglio dire è vero che lo scopo della 21 è proprio quello della verifica ma li non trovo nessun controllo sulla giacenza negativa dovrei introdurlo io mentre, nella 22, il controllo già c’è e posso semplicemente modificare parte del codice includendo il tipo movimento vendita nella condizione di controllo.
Lo dicevo per coerenza, ma in realtà hai ragione a dire che è più facile modificare la condizione nella 22. E’ una soluzione più intelligente.
Ciao
Marco
Anch’io mi sono scontrato spesso col problema delle COMMIT sulla 80 e sulla 90.
Ho tuttavia l’impressione che in NAV 2009 SP1 le cose siano cambiate.
Una tipica situazione in cui NAV assegnava il protocollo era il tenetativo di registrazione di una fattura di acquisto con External Document Number già utilizzato per lo stesso fornitore.
Bene, nella 2009 SP1 non assegna più il numero di protocollo per questa casistica di errore.
Sarebbe interessante provare negli altri casi, ve ne ricordate qualcuno?
Mah, non mi sembra. Il caso che ho segnalato accade proprio nella 2009 SP1.
Non ho mai dovuto gestire il caso che hai segnalato perchè i nostri Clienti utilizzano le funzionalità standard che mandano il magazzino in negativo.
Quindi ho provato solo con il caso che mi è capitato più di frequente (il doppio inserimento di una fattura fornitore).
Ciao
Ciao
Ad ogni modo il controllo non è molto complicato.
CodeUnit21 funzione RunCheck. Dopo la riga “TESTFIELD(“Gen. Prod. Posting Group”);” metti tutti i controlli che vuoi.
Ovviamente fa attenzione al tipo di movimento. Solo i movimenti di vendita (non di reso), i reso acquisti, le rettifiche negative e i trasferimenti.
Con un po’ di lavoro e di controlli la si fa agevolmente.
Ciao
Matteo