Ciao a tutti Stiamo utilizzando Navision Attain versione 3.10 e abbiamo rilevato diversi problemi sul punto di riordino. Volevo avere un vostro parere (conferma/correzione/suggerimenti) a riguardo. Dati questi parametri di un articolo: Giacenza iniziale: 27,00 Quantità minima d’ordine: 28,00 Sistema di Riordino: Acquisto Lead Time acquisto: 20G Scorta di Sicurezza: 10,00 Ciclo di Riordino: 7G Dimensione Lotto: 1 Lead Time Sicurezza: 1G Metodo di richiesta così configurato: Politica di Produzione: Prod. per Magazzino Calc. sotto Punto Riordino: Sì Tipo di Riordino: Lotto-per-Lotto Considera Giacenza: Sì Workdate 01/06/2004 (è un esempio) E questa configurazione di impegni/ricevimenti: Data . . . . . Demand .Supply . Giac. . Document Type . Nr. Documento 03/05/2004 .1 . . . . . . .0 . . . . .26 . . Comp.ODP . . . . ODP1 23/05/2004 .1 . . . . . . .0 . . . . .25 . . Comp.ODP . . . . ODP2 23/05/2004 .1 . . . . . . .0 . . . . .24 . . Comp.ODP . . . . ODP3 23/05/2004 .1 . . . . . . .0 . . . . .23 . . Comp.ODP . . . . ODP4 23/05/2004 .1 . . . . . . .0 . . . . .22 . . Comp.ODP . . . . ODP5 23/05/2004 .1 . . . . . . .0 . . . . .21 . . Comp.ODP . . . . ODP6 03/06/2004 .1 . . . . . . .0 . . . . .20 . . Comp.ODP . . . . ODP7 09/06/2004 .0 . . . . . . .15 . . . .35 . . ODA . . . . . . . . . ODA1 13/06/2004 .1 . . . . . . .0 . . . . .34 . . Comp.ODP . . . . ODP8 13/06/2004 .10 . . . . . .0 . . . . .24 . . Comp.ODP . . . . ODP9 13/06/2004 .1 . . . . . . .0 . . . . .23 . . Comp.ODP . . . . ODP10 27/06/2004 .1 . . . . . . .0 . . . . .22 . . Comp.ODP . . . . ODP11 L’MRP non emette nessun suggerimento di riacquisto Nè perchè siamo già sotto punto di riordino già alla partenza Nè perchè 13/06/2004 torniamo sotto punto di riordino. Cosa succede?? E’ normale?? l’MRP dorme? [:(!] Grazie per qualunque suggerimento Matteo
vorreti suggerirti di passare in 3.70 o in 2.60 … il punto di riordino in 3.10 è [xx(] un delirio … ora cerco di recuperare un po’ di info, è da un po’ di tempo che non lavoro sulla 3.10, poi ti faccio sapere. Elena
quote:
Originally posted by elbi
vorreti suggerirti di passare in 3.70 o in 2.60 …
spero tu volessi dire 3.60… Noi prima avevamo la 2.60 e visto che l’MRP era un colabrodo, ci hanno suggerito di passare alla 3.10… [:)] L’NSC che ci segue ci ha mostrato una demo della 3.60. Non so se quella demo aveva tutti i service pack installati, ma testando banalmente con 2 codici padre-figlio, l’MRP riusciva a svincolarsi meglio, ma si sbagliava comunque… Ho dato una occhiata al sorgente (codeunit inventory profile offsettings) e ho trovato diversi errori di implementazione… ma gli altri clienti, magari industrie di produzione come noi, come fanno?? Ciao e grazie per la velocissima risposta Matteo
quote:
Originally posted by Eto
quote:
Originally posted by elbi
vorreti suggerirti di passare in 3.70 o in 2.60 …
spero tu volessi dire 3.60… Noi prima avevamo la 2.60 e visto che l’MRP era un colabrodo, ci hanno suggerito di passare alla 3.10… [:)]
Ho recuperato alcune info per le anomalie, non le correzioni [V] il punto di riordino non funziona se sei già sotto punto di riordino e non hai domanda (ma tu la domana ce l’hai, quindi non so). Ricordo anche che in alcuni casi (non ho ancora trovato l’esempio specifico) il risultato è una giacenza pianificata doppia rispetto al punto di riordino. Le indicazioni del supporto Navision erano quelle di usare il punto di riordino con Tipo di Riordino: Qtà Riordino Fissa ed impostare la Quantità Riordino uguale al Punto di Riordino … il risultato era comunque un disastro. Siccome ai tempi avevamo provato ad usare il punto di riordino al posto della scorta di sicurezza (che non funzionava senza SKU) … visti i risultati alla fine abbiamo fatto la correzione per far funzionare la scorta di sicurezza, si trattava di una correzione piuttosto semplice nella codeunit Inventory Profile Offsetting.
quote:
Ho dato una occhiata al sorgente (codeunit inventory profile offsettings) e ho trovato diversi errori di implementazione… ma gli altri clienti, magari industrie di produzione come noi, come fanno??
i pochi che conosco io che usano l’MRP, l’hanno aggiustato/personalizzato.
La gestione del punto di riordino è stata completamente ripensata nella 3.70 dopo le tante critiche avute nelle versioni precedenti. Se non avete un db molto personalizzato vi conviene passare appena possibile alla 3.70 ci sono molti miglioramenti nella parte manuf e nella gestione degli impegni.
quote:
Originally posted by marcovescovo
La gestione del punto di riordino è stata completamente ripensata nella 3.70 dopo le tante critiche avute nelle versioni precedenti. Se non avete un db molto personalizzato vi conviene passare appena possibile alla 3.70 ci sono molti miglioramenti nella parte manuf e nella gestione degli impegni.
Diciamo che come clienti, la frase “upgrada che l’MRP è stato rifatto da capo perchè aveva degli errori e il nuovo funziona benissimo” l’abbiamo già sentita e la direzione non è proprio contentissima. Il database è piuttosto personalizzato sia lato NSC che cliente e quindi una migrazione completa potrebbe essere lunga. Il nostro NSC ci aveva proposto, piuttosto che passare alla 3.70, di saltare direttamente alla 4 quando uscirà. tanto, siamo 2 anni che bestemmiamo con questo MRP… aspettare qualche mese non fa molta differenza… Ciao e grazie Matteo
quote:
Ho recuperato alcune info per le anomalie, non le correzioni [V] il punto di riordino non funziona se sei già sotto punto di riordino e non hai domanda (ma tu la domana ce l’hai, quindi non so). Ricordo anche che in alcuni casi (non ho ancora trovato l’esempio specifico) il risultato è una giacenza pianificata doppia rispetto al punto di riordino.
I punti che ho rilevato io sono diversi. La funzione che restituisce se si è sotto punto di riordino restituisce falso se la giacenza prevista è GIA’ sotto punto di riordino, modificandola per prevedere anche quella condizione la situazione sembra sbloccarsi. Nei due punti (chiusura del supply e del demand) vengono passati i punti di riordino nettificati dalla scorta di sicurezza, poi quando deve rivagliare se ha trovato supply sufficienti per coprire la quantità richiesta (che è il Pdr - SS) confronta questa giacenza calcolata con un PdR nettificato da SS… mele con le pere in pratica…
quote:
Le indicazioni del supporto Navision erano quelle di usare il punto di riordino con Tipo di Riordino: Qtà Riordino Fissa ed impostare la Quantità Riordino uguale al Punto di Riordino … il risultato era comunque un disastro.
Confermo…
quote:
Siccome ai tempi avevamo provato ad usare il punto di riordino al posto della scorta di sicurezza (che non funzionava senza SKU) …
Non sono riuscito a trovare nel codice riferimenti diretti alle SKU… se non esistono vengono create fittiziamente dall’algoritmo… avevamo ricevuto anche noi questo suggerimento, ma studiando per un bel pezzo l’algoritmo, non ne vedo motivo…
quote:
Ho dato una occhiata al sorgente (codeunit inventory profile offsettings) e ho trovato diversi errori di implementazione… ma gli altri clienti, magari industrie di produzione come noi, come fanno??
quote:
i pochi che conosco io che usano l’MRP, l’hanno aggiustato/personalizzato.
e dovrebbe essere una cosa a carico della Navision Italia, Microsoft, Danimarca o quel che è… sono loro che devono garantire che la parte non personalizzata funzioni, non gli NSC/Clienti… sbaglio? Ciao e grazie mille Matteo