Articoli Taggati ‘Anagrafiche’

scritto da | on | Nessun commento

L’anagrafica articoli come visto in un post precedente rappresenta una parte fondamentale del sistema gestionale, pertanto è opportuno prevedere non solo una procedura per la creazione e l’inserimento di nuovi codici ma anche una procedura per la sua manutenzione. La manutenzione dell’anagrafica articoli è importante in quanto permette al sistema di “ragionare” con dati che riflettono la realtà. Consideriamo ad esempio il dato relativo alla confezione di un codice che non sia stato aggiornato e consideriamo ad esempio la procedura che gestisce i trasferimenti tra i vari magazzini, tale procedura calcola la quantità in eccesso su un magazzino che può essere trasferita ad un altro e poiché non è conveniente disfare una confezione nel caso di codici dal costo estremamente ridotto ( ad esempio se nel magazzino A ci sono 5230 viti e nel magazzino C ne servono 2200 ed il codice ha una confezione da 4000 è opportuno trasferire 4000 piuttosto che contare e prelevarne 2200) pertanto il sistema suggerirà di trasferire la quantità arrotondata alla confezione. È evidente che se la confezione inserita in anagrafica non è quella reale possono crearsi dei problemi. Considerando il caso di prima se in anagrafica la confezione delle viti è 4000 ma in realtà la confezione è più alta o basse l’operatore di magazzino avrebbe difficoltà nell’effettuare il trasferimento.
Per quanto riguarda la procedura di manutenzione dell’anagrafica è possibile individuare due tipi di procedure:

  1. manutenzione di massa
  2. manutenzione per singolo articolo

La procedura di manutenzione di massa prevede l’individuazione degli articoli da mantenere ed il campo od i campi che devono essere modificati. La manutenzione di massa è una operazione non sempre prevista dai gestionali pertanto in questi casi è necessario procedere accedendo direttamente alla base dati per modificare i dati tramite SQL. In questo caso possiamo avere diverse situazioni:

  • è possibile individuare gli articoli da modificare tramite una regola (cambiare tutti gli articoli che appartengono alla categoria materie di consumo, cambiare tutti gli articoli con data di creazione inferiore al 01/01/2000 ecc)
  • non è possibile individuare gli articoli tramite una regola
  • è possibile individuare il valore del campo da modificare tramite una funzione (aumentare del 10%, sottrarre 25 ecc)
  • non è possibile calcolare il valore del campo (ad esempio il fornitore ci fornisce un elenco con i suoi nuovi codici)

Vediamo con degli esempi pratici come procedere nei casi visti in precedenza.
Primo esempio: aumentare del 10% tutti i lotti minimi degli articoli del fornitore n 1820

UPDATE ANAGRAFICA SET ANAGRAFICA.[LOTTO MINIMO] = [LOTTO MINIMO]*1.1
WHERE (((ANAGRAFICA.FORNITORE)=1820));

Secondo esempio: Modificare il codice articolo fornitore per gli articoli presenti nella tabella inviata dal fornitore

UPDATE [NUOVI CODICI] INNER JOIN ANAGRAFICA ON [NUOVI CODICI].[CODICE VECCHIO] = ANAGRAFICA.[PN FORNITORE] SET ANAGRAFICA.[PN FORNITORE] = [CODICE NUOVO];

Per quanto riguarda la manutenzione di massa possiamo distinguerle ulteriormente in manutenzione periodiche e manutenzioni occasionali. Nel primo caso si tratta di aggiornamenti periodici di alcuni dati che solitamente sono calcolati tramite una procedura ad esempio la scorta minima, il lotto economico, la confezione e così via, per ogni aggiornamento è necessario quindi prevedere una procedura gestionale che informatica che consenta l’aggiornamento automatico dei dati una volta validati dagli operatori (vedi articolo verifica lead time).
Per la manutenzione del singolo articolo è necessario che la procedura preveda la responsabilità di aggiornamento dei singoli campi, i tempi di aggiornamento, le regole per la modifica. Inoltre se il gestionale lo consente individuare i campi per i quali può essere opportuno mantenere un storico (nel caso il gestionale non lo consenta è possibile prevedere una procedura a livello di database che ogni giorno effettui la copia della tabella di anagrafica per i campi di cui si vuole mantenere lo storico).

scritto da | on | 1 commento

L’anagrafica articoli costituisce il cuore di un gestionale per quanto riguarda la logistica in quanto vengono definiti in questa tabella le regole ed i parametri per la gestione fisica ed informativa del materiale, pertanto è necessario che i dati inseriti siano corretti e riflettano la situazione reale. È quindi importante definire una procedura per la codifica di nuovi codice definendo gli enti coinvolti e le informazioni di competenza ed obbligatorie. Proviamo a definire una generica procedura di codifica per quale ogni impresa potrà personalizzare in base alle esigenze. Per ogni tipologia di articolo definiamo quali sono gli uffici coinvolti e per ogni ufficio quali sono le informazione obbligatorie da definire. Ad esempio per i particolari d’acquisto gli enti coinvolti dovrebbero essere l’ufficio tecnico per le specifiche tecniche relative al prodotto, mentre l’ufficio acquisti per le informazioni relative al fornitore d’acquisto, al prezzo d’acquisto, mentre sono di competenza della logistica approvvigionamenti il lotto minimo d’acquisto, la confezione, l’ubicazione in magazzino e la modalità di riordino. Per i prodotti finiti gli uffici coinvolti saranno, l’ufficio tecnico , l’ufficio commerciale, e la logistica vendite, mentre per i materiali che vengono acquistati e poi rivenduti saranno coinvolti l’ufficio acquisti, vendite, la logistica approvvigionamenti e vendite. Una volta individuati gli uffici coinvolti e le informazioni da inserire a carico di ogni ufficio è opportuno definire per alcuni campi delle politiche di inserimento del campo, ad esempio bisogna definire una politica per la definizione della descrizione ovvero regole attraverso le quali si giunge a definire quali informazioni devono esserci nella descrizione dell’articolo ed il modo per definirle. La descrizione dipende molto da quali campi è possibile gestire per classificare l’articolo, consideriamo ad esempio la descrizione di una calzatura avremo informazioni quali il colore, il modello, il materiale ed il numero, per la descrizione bisogna prevedere quali di queste informazioni inserire e se il gestionale permette l’inserimento di campi personalizzati dove poter inserire queste informazioni. Se il gestionale permette l’utilizzo di quattro campi personalizzati li utilizzeremo per definire le informazioni viste in precedenza ed in descrizione potremmo decidere di essere generici inserendo una descrizione tipo calzatura uomo o una descrizione derivante dall’unione dei quattro campi personalizzati. Una buona pratica è quella di utilizzare i campi personalizzati in modo da rendere i dati più integri e consistenti, in quanto il campo descrizione è un campo testo nel quale è possibile scrivere di tutto. Una volta definite le regole di inserimento è bene definire le regole in casa di mancanza di un dato, ovvero cosa fare se non si ha l’informazione prevista per un campo obbligatorio, una soluzione potrebbe essere quella di inserire un dato provvisorio e modificarlo in seguito. Quindi riassumendo possiamo definire la procedura generica per la codifica di un articolo:

  1. Definizione delle tipologie di articoli
  2. Definizione degli uffici coinvolti per la codifica per le diverse tipologie di articoli
  3. Definizione delle informazione di competenza di ogni ufficio e della loro obbligatorietà
  4. Definizione delle regole di inserimento delle informazioni
  5. Definizione delle regole per i dati mancanti

scritto da | on | Nessun commento

L’anagrafica dei clienti e dei fornitori rappresenta un’insieme di informazioni vitali per l’impresa non solo dal punto di vista logistico, pertanto l’inserimento di dati rappresenta una attività che non va trascurata pur di procedere velocemente nell’emissioni di documenti. In questo post vedremo alcune problematiche relative alla procedura di inserimento dati clienti fornitori. Una prima problematica consiste nell’individuare il momento in cui un cliente od un fornitori può entrare nel nostro sistema gestionale, se il sistema lo permette è bene prevedere un campo stato relativo al cliente/fornitore, stato al quale collegare i campi obbligatori per l’inserimento del dato. Ad esempio se è previsto uno stato potenziale, significa che ancora il cliente non ha emesso un ordine oppure non abbiamo ancora effettuato un ordine al fornitore, in questa fase campi come le coordinate bancarie o il vettore di riferimento o la modalità di pagamento possono essere tranquillamente non essere compilati anche perché molto probabilmente ancora non avremo queste informazioni.

Altra problematica è relativa alle relazioni che possono intercorrere tra i clienti fornitori ad esempio potremmo avere tra i clienti aziende che appartengono allo stesso gruppo per le quali ci saranno informazioni comuni, oppure tra i fornitori potremmo avere il produttore diretto ed un suo rivenditore, è quindi opportuno evidenziare in qualche modo queste relazioni all’interno dell’anagrafica.

Altra problematica è quella relativa alla compilazione dei campi per i quali è bene prevedere dove possibile dei campi tabulati che fanno cioè riferimento a delle tabelle, altrimenti ci troveremo nel campo modalità di pagamento dati come 30 DF o 30 GG DF ed altre amenità (può sembrare un consiglio banale ma molto spesso si ha la fretta di inserire il dato perché magari c’è il DDT da  stampare urgentemente). Un campo non tabulabile che richiede attenzione è quello dell’indirizzo, in modo particolare per i clienti un inserimento quanto più standardizzato possibile rende poi facile una eventuale attività di geomarketing.

Infine si presenta il problema delle imprese che cambiano ragione sociale per cui si presentano due possibilità: modificare la ragione sociale, o creare un nuovo record ed annullare il precedente associando tutte le relazioni con il nuovo (contratti, DDT, Fatture ecc). La seconda operazione è decisamente molto più onerosa ed andrebbe adottata unicamente nel caso in cui ci siano gravi pendenze con la società precedente.

News