Data ultimo aggiornamento: 12/02/2019

Attivazione versione distinta base e cicli

Moduli richiesti: Distinta Base e Analisi Fattibilità Impegni

Il programma in questione permette di attivare la versione per distinta base e cicli, anche questo è lanciabile oltre che da menu, anche dal programma di personalizzazione produzione.

Una volta lanciato e attivato l'uso della versione in distinta base, setterà un campo nella personalizzazione produzione (non modificabile).

La versione distinta base è un utilizzo alternativo delle revisioni a data validità nelle distinte base, invece che usare la storicizzazione con le date di validità nelle revisioni, si usano le versioni, sia che siano materiali sia che siano cicli di lavorazioni. Permette quindi di scegliere in alternativa di storicizzare la distinta base, in base ad un identificativo alfanumerico chiamato versione, attivando la gestione non avremo più data inizio/fine validità su materiali e lavorazioni, ma avremo da versione a versione.

Il programma di attivazione fa delle operazioni per fare partire in automatico le versioni su tutti gli articoli, andando a vedere la storia delle distinte, fa una differenza per data e si costruisce a partire dalla versione 000 (la prima), tutte le versioni in base alle revisioni a data. Per cui attivando questa gestione su un database già avviato da tempo, potremmo trovare che PFF parte da versione 010, perché c'è tutta la storia ricostruita.

Per esempio andando a vedere in una distinta base potremmo trovare, una volta attivata la gestione, una situazione di questo tipo, dove si vedrà la versione corrente (che sarà di tipo tutto numero, alfanumerica o in parte numero ed in parte alfanumerica, a seconda di quanto scelto nel programma di attivazione). Nella distinta base per materiali e lavorazioni ci sono ovviamente i nuovi campi da versione a versione, nell'esempio sotto troviamo che alla versione 003 è stato introdotto un nuovo materiale. NB: nella versione corrente non è obbligatorio che ci sia sempre l'ultima, infatti è possibile indicare una versione di distinta qualsiasi tra quelle disponibili.

Quando si manipolano le distinte basi a versione, c'è lo zoom sulle versioni che però in realtà mostra un aggregato fra versioni e le note di versione di distinta base. Per gestire facilmente le versioni, nella toolbar strumenti c'è una nuova voce "assegna il numero di versione successivo", che permette in modo agevole di creare una nuova versione. La funzione calcola e propone il nuovo numero di versione in una prima finestra e poi apre anche una seconda finestra per compilare le relative note di versione (obbligatorio altrimenti non fa salvare e uscire), quindi ad ogni versione corrisponde sempre un record di note di versione descrittivo. Per creare una nuova versione si può anche scrivere direttamente nel campo versione corrente nella finestra principale della distinta base il nuovo codice, questo non fa altro che richiamare la finestra di creare una nuova versione come se si fosse scelta la voce dalla toolbar.

Nella finestra delle note di versione è possibile indicare, oltre ad una descrizione, anche un file di qualsiasi tipo tramite il campo disegno. Notare che c'è anche la possibilità indicare oltre alla nostra codifica interna, anche la codifica che ha dato il cliente o terzista a questa nuova versione (dato di cui si avrà visione nello zoom delle versioni).

L'utilizzo della ''versione'' di distinta (non inventariale) sia per la parte materiali che per la parte cicli, per gestire le variazioni tecniche , serve quindi per gestire la versione delle distinte basi NON PER DATA DI VALIDITA' ma per identificativo di versione (alfanumerico).

Quando attivata l'MRP esploderà per versione corrente se l'articolo NON E' GESTITO A COMMESSA O/I/M (piena), mentre esploderà la versione indicata nell'impegno, se l'articolo è GESTITO A COMMESSA O/I/M (piena). Tutto ciò perché la pianificazione MRP NON AVVIENE PER VERSIONE, ma se si gestisce l'articolo a commessa O/I/M allora poiché l'MRP pianifica a COMMESSA e di fatto PIANIFICA anche a versione.

In Proposte/Ordini/Carichi di produzione è possibile impostare manualmente la versione come dato di riga (automaticamente propone la corrente ma può essere cambiata dall'operatore), negli impegni (clienti, di produzione, ... tutti) anche qui è possibile indicare la versione sulla riga (anche qui propone la corrente), ma ciò è significativo solo su un articolo gestito a commessa piena.

Inserendo un ordine di produzione quando è attiva questa gestione si può notare che non chiede più la data di validità della distinta base, inoltre una volta esplosi gli impegni collegati se in questi ci sono dei semilavorati, anche su questi ritroveremo il campo relativo alla versione compilato a quella corrente.

Sugli impegni collegati se volessimo che venisse proposta la stessa versione del padre, invece di proporre la versione corrente del semilavorato, occorre intervenire in distinta base sulla griglia dei materiali sul semilavorato, attivando il flag usa versione padre.

Mettendo questa spunta quando l'MRP esplode la distinta base del padre e calcola gli impegni figli, invece di mettere negli impegni la versione corrente mette la stessa versione del padre, ovvio che quando si lavora così il semilavorato deve avere nelle sue versioni quella del padre.

In questo scenario ci sono 2 opzioni di registro utili:

• BSDBDIBA\OPZIONI\NoRichiestaApplicaNuovaVersione se attivata alla creazione di una nuova versione tramite la funzione "assegna il numero di versione successivo", chiede all'utente se si vuole applicare la nuova versione ricorsivamente su tutti i figli.
• BSDBDIBA\OPZIONI\DefaultSiApplicaNuovaVersione se attivata alla domanda attivabile con l'opzione NoRichiestaApplicaNuovaVersione il default è sul Sì. In realtà è anche possibile attivare anche solo questa opzione, in automatico alla creazione di una nuova versione tramite la funzione "assegna il numero di versione successivo", tale versione verrà attivata automaticamente sui figli. Un secondo effetto che genera l'attivazione di questa opzione è che sulla griglia dei materiali, quando si inserisce un nuovo componente di default viene messo il flag sulla colonna usa versione padre.

NOTA BENE: la versione non deve essere intesa come variante di un prodotto in funzione di un cliente (questo mai), la versione è legata ad un discorso di sequenzialità di formula di produzione di un prodotto nel tempo, e non come contemporaneità di versioni diverse perché una versione la mando ad un cliente e un'altra ad un altro cliente, questo è fondamentale!