Righe splittate nei trasferimenti con conseguente errore nel carico!!

Ciao a tutti,

ieri sono diventato pazzo (ma forse lo ero già) con il seguente problema nella versione 3.70 (SQL ma poco importa) aggiornata con tutti i SP.

Avevo alcuni ordini di trasferimento con tante righe (circa 200-300 a ordine). Al momento del posting della spedizione andava tutto bene, mentre al momento del carico mi diceva che l’articolo tal dei tali non era a magazzino. Poiché l’articolo era a magazzino (lo avevo appena spedito!!), e poiché rilanciando il posting talvolta andava a buon fine, talvolta invece cambiava il codice dell’articolo in questione, mi sono domandato da dove potesse venire il problema.

Ho scoperto così che quando si registra una spedizione da un ordine di trasferimento, ogni tanto il sistema splitta la riga. Tipo: devo spedire 13 pezzi, lui mi crea 2 movimenti: uno da 8 e uno da 5! In questi casi, quando poi registri il carico, il sistema cerca il movimento di spedizione corrispondente, presume che ce ne sia solo uno, lo trova (nel caso di prima quello da 8) e quindi ne deduce che non c’è giacenza a sufficienza per caricare la merce! Carino no? Oltretutto, visto che appunto al secondo lancio spesso il problema spariva o cambiava codice, ma si bloccava sempre e comunque sui codici splittati, sono davvero impazzito a correggere il problema (che alla fine sono riuscito a sistemare nella codeunit 22).

La mia domanda è però questa: qualcuno sa quando il sistema decide di splittare una spedizione in 2 (o forse più) movimenti? Davvero non capisco che tipo di giro faccia e comunque non ho ancora capito perché nei carichi talvolta non dia problemi e talvolta invece sì.

Ah, un’ultima cosa: il cliente non usa il warehouse, le collocazioni, i lotti e i numeri di serie o la produzione, quindi era davvero una situazione banale. Oltretutto lavoravo su un database di test con nessuno collegato.

Ciao a tutti

Marco

Ciao Marco,

magari non c’entra nulla, ma a me dava lo stesso messaggio di articolo non a magazzino con gli articoli con Politica di Tracciabilità Ordini impostata a Solo Tracciabilità (o comunque non Nessuna), creando un po’ di casino nella reservation entry. Lo stesso problema lo avevo poi sul magazzino del terzista usando il conto lavoro quando registravo i consumi, problema aggirato impegnando ogni volta i componenti una volta spediti (pensa com’era contento il cliente…). Idem con i lotti e nr. serie quando provavo a fare una spedizione di un ordine di vendita.

Avevo anche segnalato la cosa al supporto MBS, e pare fosse cosa nota, infatti con la 4.0 sembra tutto sistemato tranne la gestione lotti/nr. serie che fino a prima della sp1 dava ancora problemi con la politica di tracciabilità ordini. Dopo la SP1 non l’ho ancora testato.

Che magari la Tracciabilità Ordini comporti lo split delle righe un funzione dei legami (o supposti tali) che riscontra salvo poi perdersi per strada quando li ricerca? Mistero… io ho preferito evitare di utilizzare la Tracciabilità Ordini.

Ciao, Max

Per quanto ne so lo split viene fatto quando la spedizione in origine consuma N carichi diversi, questo per trasferire al magazzino di destinazione i costi nel modo corretto.

es.

carico 100 costo 10

carico 100 costo 15

trasferisco 150, se non sbaglio dovresti trovare:

uno scarico per 150 e due carichi sul magazzino di transito uno di 100 a 10 e uno di 50 a 15 (salvo che tu abbia il metodo dei costi LIFO che scaricherebbe prima il secondo carico)

E’ vero, splitta nel caso di costi diversi, ma da un test banale il carico me lo fa…quindi evidentemete non basta. La tracciabilità non l’ho provata percé il cliente non la usa su nessun articolo, né usa l’impegno…che casino!

Io mi son trovata invece, nella 4.02, con una serie di record di tracciabilita’ legati a ordini di produzione, sebbene nessuno dei miei articoli usi la tracciabilita’.
Il problema che ne consegue e’ che, se si tenta di registrare un output con quantita’ superiore a quella prevista, viene fuori un errore “Asserzione non riuscita: Impegno” dovuto al fatto che quando genera i movimenti di scarico automatico dei materiali collegati all’operazione, fa PRIMA lo scarico della tracciabilita’ e DOPO lo split delle quantita’.
Non so perche’ vengano generati questi record di tracciabilita’, che nessuno gli ha chiesto, comunque non dovrebbero interferire con l’avanzamento della produzione. Nella 3.70 non accadeva. [8-)]

Alla fine credo sia un problema legato ad un comportamento anomalo dell’istruzione NEXT nella funzione di collegamento dei movimenti articoli. Non so per quale motivo in alcune situazioni non legge un movimento che ha in canna ma esce dalla funzione prima di elaborarlo, il tutto perché l’istruzione di NEXT restituisce il valore zero anche se trova il record! Su mibuso qualcuno mi ha detto che il problema era stato risolto con il client 3.70B, il che mi fa pensare che davvero sia un problema di istruzione C/AL, o magari è anche legato ad SQL.

Comunque io l’ho risolto aggiungendo una condizione alla NEXT fatidica, in sostanza dicendogli di uscire solo se non ha in canna un record nuovo…funziona, ma spero non combini qualche casino.

Marco