Infine è analizzato come il BMS memorizza e gestisce, all’interno del database, la storicità di un dato, le liste di prelievo, gli ordini dei clienti e gli ordini di produzione

(1)

23 2. IL GESTIONALE BMS

All’interno di questo capitolo, proseguendo l’analisi della realtà aziendale iniziata nel capitolo 1, andiamo a focalizzare l’attenzione sul gestionale presente in azienda.

È data, inizialmente, una breve panoramica dell’azienda che ha sviluppato il gestionale BMS e alla quale è stato commissionato l’automa dei prelievi.

Poi è presentata l’architettura del gestionale e descritti gli standard di codifica inerenti a tabelle, dati e codice PL/SQL. Infine è analizzato come il BMS memorizza e gestisce, all’interno del database, la storicità di un dato, le liste di prelievo, gli ordini dei clienti e gli ordini di produzione. Tutto ciò è propedeutico allo sviluppo dell’automa dei prelievi in quanto questo deve essere il più possibile integrato con il gestionale preesistente.

2.1 Time s.r.l: profilo aziendale

Il gestionale BMS è stato sviluppato dal gruppo Time. T.I.M.E. SRL, di seguito chiamata Time, viene fondata nel 1983 come società di ingegneria informatica per applicazioni gestionali dedicate a grosse aziende della provincia di Lucca operanti con sistemi proprietari dell’allora partner di riferimento.Honeywell-Bull,

Nel corso degli anni ’90 Time vede crescere sia la propria offerta, con il rilascio di una soluzione gestionale su piattaforma standard Unix denominata X-Time, sia la propria presenza nel mercato regionale Toscano e del centro Italia, mediante l’acquisizione di importanti commesse di fornitura di sistemi gestionali.

In questi anni si consolida la vocazione di Time verso l’analisi dei processi aziendali e la conduzione di progetti di customizzazione di applicazioni gestionali sulle specifiche esigenze del Cliente, favorendo la crescita della struttura operativa in termini di sviluppatori e consulenti applicativi, ma anche di personale commerciale e tecnico-sistemistico per rispondere a 360° alle richieste IT dei propri clienti.

La fine degli anni ’90, a culmine di anni di crescita e consolidamento sia di mercato che di competenze e know how, è caratterizzata da una svolta storica per Time: la decisione di realizzare un sistema ERP completamente nuovo e con caratteristiche sia tecnologiche sia applicative di alto livello, per rispondere alle esigenze del mercato delle PMI di fascia medio alta.

Nasce così BMS, acronimo di Business Management System, partendo dal patrimonio di esperienze maturate su oltre 150 installazioni di gestionali, ma senza ereditare una riga di codice dal predecessore X-Time, riscrivendo cioè tutta la logica applicativa con nuovi strumenti allo stato dell’arte.

Per la scelta degli strumenti (Oracle come DB e PowerBuilder come sviluppo visuale) e l’acquisizione di competenze sulle tecnologie di sviluppo da utilizzare viene stretta una partnership con una struttura specializzata nell’outsourcing tecnologico, PlanGroup, con la missione di arrivare ad una prima release di prodotto da affinare successivamente in autonomia.

Nella seconda metà del 1999, quindi dopo circa due anni di sviluppo, vengono effettuate le prime installazioni operative di BMS su alcuni clienti pilota, che ad oggi continuano ad essere partner di Time.

Il considerevole investimento economico della realizzazione di BMS, pari a circa 2,5 milioni di euro, viene coperto parzialmente dai profitti derivati dalle attività legate all’introduzione dell’euro e dell’anno 2000 sul parco clienti, per il restante dal reinvestimento completo di tutti gli utili aziendali.

Dal 2000 ad oggi Time ha vissuto anni di continua crescita in termini di fatturato, di clienti e di personale, andando in controtendenza rispetto alla crisi generalizzata del settore dovuta alla scarsità di investimenti nell’IT da parte delle imprese.

(2)

24 Ad oggi Time può contare su oltre 180 clienti X-Time e oltre 90 clienti BMS, questi ultimi generalmente PMI dai 20 ai 400 mil/euro di fatturato.

La struttura attuale è di circa 60 addetti, prevalentemente concentrati nella sede operativa di Capannori, Lucca, e di 10 addetti nelle sedi logistiche sul territorio di Sassari, Verona e Ancona.

Nel corso del 2007 è in programma la creazione di una importante unità operativa al sud, per la realizzazione di progetti speciali in ambito BMS e per la diffusione dei prodotti e servizi Time sul mercato locale.

Ad oggi Time si propone sul mercato come un produttore di sistemi ERP a livello nazionale, con una spiccata capacità progettuale e con una capacità di copertura completa delle esigenze dell’IT di una impresa moderna, offrendo servizi che vanno dalla consulenza organizzativa per i processi logistici e produttivi, fino alla realizzazione di infrastrutture networking, passando ovviamente per la conduzione di progetti ERP, vera mission aziendale.

Importanti esperienze sono state conseguite in alcune applicazioni verticali per le aziende di produzione su commessa, tra cui la cantieristica navale, per la quale Time è leader nazionale, e la logistica avanzata per aziende di distribuzione no-food.

Il prodotto BMS si colloca nella fascia intermedia che sta tra gli applicativi di tipo pacchettizzato generalmente venduti tramite canali distributivi e gli ERP internazionali quali SAP, Oracle Application, JDE ecc.

I partner tecnologici di Time sono importanti vendor come IBM, Oracle, Sybase, Cognos e PSC.

A completamento della propria offerta di soluzioni per l’impresa Time è in grado di condurre progetti di system integration con sistemi di logistica quali magazzini automatici, di gestire progetti di business intelligence e data-warehouse, di realizzare sistemi di sales force automation e di BtoB.

2.2 Architettura dell’ Erp esistente

Il sistema Erp (Enterprise Resource Planning) esistente, denominato BMS (Business Management System), è un’applicazione client/server three-tier (3 livelli).

Fig. 14 Logo BMS

(3)

25 L'architettura di tipo two-tier è il modello tradizionale client/server, costituito da un programma client (primo livello) che interagisce direttamente con il livello di archivio dati (secondo livello). Sui client è presente sia il software (librerie e drivers) con cui accedere al livello archivio dati, sia il software di gestione dell'interfaccia utente.

Questo rappresenta il maggior inconveniente dell’architettura two-tier, perché comporta di installare o scaricare via rete le librerie per accedere ai DBMS (Database management system).

L’architettura three-tier, invece, è un'evoluzione dell'architettura client/server in quanto è contemplato un nuovo modulo intermedio (middleware) per la gestione del trasferimento dei dati dal livello client al livello archivio dati.

Il modulo middleware rende indipendente il livello client dalle problematiche di accesso al livello archivio dati. Essendo il livello client indipendente dal livello archivio dati, la comunicazione fra il client e il middleware avviene tramite protocollo standard.

Nell'architettura three-tier vengono coinvolti tre livelli:

• il livello presentazione

• il livello intermedio (middleware)

• il livello archivio dati

Il livello di presentazione rappresenta l'interfaccia utente dell'applicazione nell'intento di acquisire dati e visualizzare i risultati.

Il livello intermedio si occupa di inoltrare le richieste dell'utente al livello archivio dati e di trasmettere i relativi risultati.

Il livello archivio dati rappresenta l'insieme dei servizi offerti da applicazioni indipendenti dal livello intermedio; nel nostro caso tale livello sarà costituito da DBMS Oracle.

Nello specifico del ERP in questione la struttura a three-tier è composta da:

• Il database server contiene il DBMS Oracle e le varie istanze richieste dalla specifica installazione (tipicamente Produzione e Test)

• L’application server contiene il BMS application server ovvero una applicazione non visuale che ha il ruolo di server per l’applicazione client: il suo scopo è quello di eseguire elaborazioni complesse e/o richiedenti elevate risorse in termini di tempo e capacità di elaborazione (tipicamente batch) in modo asincrono ; gestisce inoltre lo spool di stampa;

• Il client contiene l’applicazione BMS visuale, implementato in Power Builder 6.5

Fig. 15 Architettura BMS

(4)

26 2.3 Descrizione degli standard di nomenclatura utilizzati

Nella sviluppo del gestionale BMS sono stati utilizzati alcuni standard nella nomenclatura delle tabelle, delle store procedure e delle funzioni affinché il codice risultasse il più omogeneo possibile e ci fosse una più semplice collaborazione fra i vari programmatori del team. Per informazioni specifiche sul database Oracle e il codice associato si rimanda al capitolo 3.

2.3.1 Nomenclatura tabelle del database

Le tabelle create all’interno del database Oracle, nelle quali sono memorizzati i dati del gestionale BMS, hanno:

• Un nome

• Un codice

• Una descrizione

Il nome ha una lunghezza massima di 10 caratteri ed è un codice non univoco legato all’utilizzo di trigger generalizzati per l’esecuzioni di funzioni comuni.

Il codice ha una lunghezza massima di 10 caratteri ed è un codice univoco all’interno del database; questo è il nome della tabella utilizzato in tutto il codice PL/SQL e nelle query.

La descrizione ha una lunghezza massima di 75 caratteri. Questa, di solito, riporta una breve spiegazione dello scopo della tabella stessa.

Esistono tabelle speciali dette phantom il cui codice ha come suffisso P_ e il loro nome termina con p. Queste sono composte da sola una parte della chiave primaria della corrispondente tabella non phantom associata, quella il cui codice inizia senza P_. Le tabelle phantom sono utilizzate come riferimento nelle foreign key di altre tabelle quando è impossibile riferirsi alla tabella normale (quella non phantom) a causa della presenza in chiave della data di inizio validità usata per la memorizzazione della storicità di un dato, in quanto può non essere conosciuta.

In generale si seguono i seguenti standard:

• Il nome è dato da area + argomento+(_p)

• Il codice è dato da (P_)+(codice_società)+area+argomento

I valori tra parentesi tonde sono opzionali. Il simbolo + indica il concatenamento di stringhe. Il codice della società entra in gioco nel momento in cui viene creata una tabella che esce dallo standard BMS di base per realizzare una personalizzazione per tale società.

Le aree utilizzate sono:

• AN anagrafiche generali

• AF amministrazione e finanziaria

• CA contabilità analitica

• GE tabelle di utilizzo generico

• LG logistica

• PR produzione

Un esempio di nomenclatura delle tabelle è

• Codice: LGARTMAG

• Descrizione: Logistica descrizione articoli di magazzino

(5)

27 2.3.2 Nomenclatura dati

I dati e quindi i campi delle tabelle del database hanno:

• Un nome

• Un codice

• Una label

Il nome ha una lunghezza massima di 75 caratteri e serve per scopi documentativi.

Il codice ha una lunghezza massima di 13 caratteri, lunghezza minima 5 caratteri e si cerca di mantenere come lunghezze ammissibili 5, 11, 13 caratteri; questo codice è univoco all’interno della tabella e rappresenta il nome della colonna stessa.

La label è la descrizione sintetica usata nelle testate dei campi applicativi.

In generale lo standard seguito è:

• Il nome è dato da classe congiunzione argomento ripetuto secondo necessità. Tutte le componenti sono scritte per esteso; ad esempio, ammontare del progressivo della scadenza in Euro. (nell’esempio è stato ripetuta la sequenza due volte)

• Il codice è dato da classe+argomento_congiunzione+specificazione_progressivo (o carattere) ad esempio APROG_DSCAD_E. Tutti gli elementi sono espressi in forma contratta.

Le classi ammesse sono:

• A ammontare

• B flag di un carattere (ad esempio S o N)

• C codice

• D data

• F data di fine

• G giorno

• I data inizio validità

• L blob (oggetto multimediale)

• M mese

• N numero

• O oid (chiave surrogata)

• P percentuale

• Q quantità

• R nome

• S data d’inizio

• T testo descrittivo

• Y anno

Le congiunzioni ammesse sono:

• C con (mediante)

(6)

28

• D del(la)

• E e

• I in

• L dal(la)

• N nel(la)

• O o

• P progressivo

• S specificatamente

• T tra

• X per

Per chiarire lo standard di nomenclatura dei dati di seguito elenco alcuni esempi CANAG_SCLIE Codice ANAGrafico Specificatamente al CLIEnte BSTOR Flag per la STORicità

2.3.3 Nomenclatura dei vincoli sulla tabella I vincoli su una tabella hanno:

• Un nome

• Un codice

Entrambi di lunghezza massima pari a 19 caratteri e seguono il seguente standard:

Nome tabella_tipo + numero

I tipi e i relativi valori per il campo numero ammessi sono:

Tipo Numero

• AK Alternate key progressivo

• FK Chiave esterna progressivo

• PK Chiave primaria nessuno 2.3.4 Nomenclatura procedure e funzioni

Le funzioni e le store procedure hanno:

• Un nome

• Un codice

Questi due sono uguali e hanno un limite di caratteri pari a 19 caratteri ed seguono il seguente standard:

tipo_argomento I tipi ammessi sono:

• FNC Funzione di controllo (senza aggiornamenti sulla banca dati)

• FNU Funzione di aggiornamento

(7)

29

• PKG Package oracle (raggruppa funzioni e procedure sotto un unica entità)

• SPC Store procedure di controllo (senza aggiornamenti)

• SPU Store procedure di aggiornamento

2.4 Descrizione del sistema di gestione e memorizzazione del BMS

In questo paragrafo si analizza come il BMS memorizza e gestisce, all’interno del database, la storicità di un dato, le liste di prelievo, gli ordini dei clienti e gli ordini di produzione. Tutto ciò è propedeutico allo sviluppo dell’automa dei prelievi in quanto questo deve essere il più possibile integrato con il gestionale preesistente.

2.4.1 Convenzione descrizione delle tabelle dati

Proseguendo nell’analisi la struttura delle tabelle dati sarà riportata all’interno del testo in schemi con la seguente intestazione:

• Name : riporta il nome del campo della tabella

• Type: è il tipo del campo

• Nullable: se Y significa che il campo può assumere il valore null, se N no

• Default: riporta il valore predefinito del campo

• Descrizione: riporta il significato del campo

I campi delle tabelle possono essere utilizzati in toto o in parte. Alcune società, infatti, possono dover gestire un numero di informazioni inferiori ai campi contenuti all’interno delle tabelle dello standard BMS. In sede di analisi saranno evidenziati i campi inutilizzati lasciando vuoto il campo descrizione. I campi evidenziati di colore blu, poi, sono oggetto di un commento approfondito che è riportato in paragrafi appositi o di seguito alle tabelle stesse.

2.4.2 Storicità di un dato

Se voluto, i dati di un particolare record vengono conservati storicamente insieme alla data in cui è stata fatta ogni modifica. All’interno del BMS per gestire la storicità di un dato è utilizzato un campo dati denominato BSTOR di tipo carattere e un campo data.

Il campo BSTOR assume valori diversi se il record è attuale, se è un dato storico o se entrerà in vigore in futuro:

• A: il dato è attuale

• P: il dato è un dato storico

• F: il dato entrerà in vigore in futuro passando alla stato A

Di conseguenza all’interno di una tabella per un determinato dato ci sarà un solo record con BSTOR pari ad A e ci potranno essere molti record con BSTOR pari a P. Questi ultimi rappresentano la storicità del dato.

2.4.3 Oid o chiave surrogata

Il concetto di oid o chiave surrogata è molto importante all’interno di un database. Una chiave surrogata è una chiave primaria univoca generata dal DBMS stesso che non è legata a nessun dato nel database e il cui unico significato è quello di essere una chiave primaria o parte di una chiave primaria per la tabella. Un esempio tipico di chiave surrogata è un contatore sequenziale.

(8)

30 All’interno del BMS si fa uso di oid in tutti quei casi in cui si voglia preservare la storicità di un dato. Ogni oid, quindi, sarà associato al campo di cui vogliamo preservare la storicità.

Un esempio all’interno del database BMS è il campo OARTI della tabella LGARTMAG.

Questo campo è l’oid del codice articolo vero e proprio (CARTI). La chiave primaria di questa tabella è composta dai campi CSOCI (codice della società), OARTI (oid), IARTI (data di inizio validità del dato). In questa tabella sono memorizzati le anagrafiche degli articoli contenuti nei vari magazzini dell’azienda.

Per ogni articolo stoccato all’interno dei magazzini, anche in maniera discontinua, saranno conservate tutte le versioni della sua anagrafica. Ad esempio l’art. 0011 ha come record quelli di Fig. 16.

CSOCI OARTI IARTI BSTOR CARTI BALD 55 04/01/2006 P 0011 BALD 55 05/06/2006 P 0011 BALD 55 06/09/2006 A 0011

In questo esempio abbiamo preservato la storicità di due modifiche apportate all’anagrafica dell’articolo: una avvenuta il 04/01/2006 e l’altra in data 05/06/2006. Le altre informazioni di ogni record che contengono l’anagrafica dell’articolo sono state omesse.

Ogni volta che si deve risalire, quindi, ad un dato memorizzato all’interno di una tabella con storicità devo essere messo come criterio alla clausola where il BSTOR = ‘A’.

Per convenzione nel proseguo dell’analisi per tutti i campi oid verrà riportata tra parentesi tonde, nella colonna descrizione, la tabella, all’interno della quale, si trovano le informazioni legate a quel oid.

2.4.4 Gestione delle liste di prelievo

Le informazioni riguardanti le liste di prelievo sono memorizzate all’interno di due tabelle temporanee:

• T_BLEVAO01

• T_BLEVAO02

2.4.4.1 T_BLEVAO01: informazioni della lista di prelievo

In T_BLEVAO01 sono contenute tutte le informazioni che caratterizzano una lista di prelievo. Tali informazioni sono visualizzabili all’interno della Fig. 17. Si ricorda che un esempio di lista di prelievo è visibile in Fig. 10.

Nome campo Tipo campo Nullable Valore di default

Descrizione

OELEN NUMBER N Numero della lista di prelievo NPROG_IELEN NUMBER N Numero riga lista di prelievo CSOCI VARCHAR2(4) Y Codice della società

CREPA VARCHAR2(8) Y

CCAUS_SDOCU VARCHAR2(8) Y '0' Causale ordine cliente

YCALE NUMBER Y 0 Anno ordine cliente

NPROT_DDOCU NUMBER Y 0 Numero protocollo ordine cliente

NRIGA_DDOCU NUMBER Y Numero della riga ordine cliente BSTAM NUMBER Y Stato della lista di prelievo

Fig. 16 Esempio di storicità

(9)

31

NLIVE_DPREF NUMBER Y

CTIPO_DMAGA VARCHAR2(4) Y Tipo magazzino

CMAGA VARCHAR2(8) Y Codice magazzino

CUBIC VARCHAR2(24) Y Codice ubicazione cliente CTIPO_DLOTT VARCHAR2(4) N '0'

CLOTT VARCHAR2(24) N '0'

BFORZ VARCHAR2(1) N 'N'

CANAG_SFORN NUMBER(38) N 0

CIMBA VARCHAR2(4) N '0' Codice dell’imballo QLOTT_SCOMM NUMBER Y

QARTI_NUBIC NUMBER Y Quantità in lista di prelievo

OARTI NUMBER Y Oid articolo (LGARTMAG)

QRIGD_DEVAD NUMBER Y BDEFI_OPROV VARCHAR2(1) Y

DAGGI DATE Y Data della lista di prelievo

CUSER NUMBER N 0

CFUNZ NUMBER(38) Y

CTIPO_DLOTT_O VARCHAR2(4) N '0' CLOTT_SORDI VARCHAR2(24) N '0'

CGIUS VARCHAR2(4) Y '0'

CUSER_DINSE NUMBER Y 0

DAGGI_DINSE DATE Y

CUSER_DAPER NUMBER Y 0

DAGGI_DAPER DATE Y

CUSER_DCHIU NUMBER Y 0

DAGGI_DCHIU DATE Y

CUSER_DCTRL NUMBER Y 0

DAGGI_DCTRL DATE Y

NCEST NUMBER Y 0

NPREL NUMBER Y 0

CUSER_DGIUS NUMBER Y

DAGGI_DGIUS DATE Y

CPVEN VARCHAR2(8) Y '0'

ORAGG NUMBER Y

NTAGL NUMBER Y Oid taglia (BLTAGLIE)

CFORM VARCHAR2(8) Y Codice forma

CFOND VARCHAR2(8) Y Codice fondo

CCOLO VARCHAR2(8) Y Codice colore

CVETT VARCHAR2(4) Y Codice vettore

CANAG_SCLIE NUMBER(38) N 0 Oid cliente (ANCLIENT)

In una lista di prelievo avrò una riga per ogni taglia di ogni articolo, comb. colore, fondo, forma.

2.4.4.1.1 Stato della lista di prelievo

Lo stato di una lista di prelievo è dato da uno dei seguenti valori del campo BSTAM :

• 0: lista di prelievo creata ma né stampata né evasa (lista “aperta”)

• 1: lista di prelievo stampata ma non evasa (lista “aperta”) Fig. 17 Campi tabella T_BLEVAO01

(10)

32

• 2: lista di prelievo parzialmente o totalmente evasa 2.4.4.2 T_BLEVAO02: informazioni sulle calzature imballate

La tabella T_BLEVAO02 permette la gestione di liste di prelievo evase parzialmente.

Questa situazione si può verificare quando il magazziniere si reca ai vari scaffali per prelevare gli articoli indicati sulla lista. È verosimile, infatti, che alcuni articoli, per errori di gestione del magazzino, non siano realmente disponibili sugli scaffali. L’operatore, allora, si reca alla zona d’imballaggio dove prepara il collo, leggendo con la pistola ottica i codici a barre degli articoli disponibili. Ogni lettura della pistola ottica viene registrata all’interno della T_BLEVAO02. In questa tabella, quindi, sono registrati i singoli movimenti di imballaggio associati ad una determinata lista di prelievo. La lista di prelievo in questione rimane “aperta”

a causa della paia non disponibili.

La struttura della T_BLEVAO02 è presentata in Fig. 18.

Name Type Nullable Default Descrizione

OELEN NUMBER N Numero della lista di prelievo NPROG_IELEN NUMBER N

Numero della riga della lista di prelievo

NSEQU NUMBER N

Contatore letture per la lista di prelievo

CSOCI VARCHAR2(4) Y Codice della società

CREPA VARCHAR2(8) Y

CCAUS_SDOCU VARCHAR2(8) Y '0'

YCALE NUMBER Y 0

NPROT_DDOCU NUMBER Y 0

NRIGA_DDOCU NUMBER Y

BSTAM NUMBER Y Stato della lista di prelievo NLIVE_DPREF NUMBER Y

CTIPO_DMAGA VARCHAR2(4) Y Tipo del magazzino

CMAGA VARCHAR2(8) Y Codice del magazzino

CUBIC VARCHAR2(24) Y Codice ubicazione

CTIPO_DLOTT VARCHAR2(4) N '0'

CLOTT VARCHAR2(24) N '0'

BFORZ VARCHAR2(1) N 'N'

CANAG_SFORN NUMBER(38) N 0

CIMBA VARCHAR2(4) N '0'

QLOTT_SCOMM NUMBER Y

QARTI_NUBIC NUMBER Y

OARTI NUMBER Y Oid articolo (lgartmag) QRIGD_DEVAD NUMBER Y Quantità evasa

BDEFI_OPROV VARCHAR2(1) Y

DAGGI DATE Y

CUSER NUMBER N 0

CFUNZ NUMBER(38) Y

CTIPO_DLOTT_O VARCHAR2(4) N '0'

CLOTT_SORDI VARCHAR2(24) N '0'

CPVEN VARCHAR2(8) Y '0'

NIMBA NUMBER(38) Y Numero del collo CCAUS_SMAGA_P VARCHAR2(8) Y '0'

(11)

33 YCALE_DPREB NUMBER Y 0

NPROT_DMOMA_P NUMBER Y 0

Le informazioni in questa tabella, affinché siano complete, si devono legare con quelle presenti in T_BLEVAO01 tramite i campi OELEN e NPROG_IELEN, che, ricordo, sono rispettivamente il numero della lista di prelievo e il numero della riga della lista. In T_BLEVAO02, infatti, non sono presenti informazioni come la combinazione colore, il fondo ecc.

All’interno della lista di prelievo possiamo avere sulla stessa riga una quantità per taglia maggiore di uno mentre all’atto della lettura con il codice a barre si legge un paio alla volta.

Per questo è stato inserito il campo NSEQU all’interno di T_BLEVAO02. NSEQU è un contatore progressivo che viene incrementato ad ogni lettura di un codice a barre. Ogni singola “sparata” è identificata dalle seguenti informazioni: numero della lista di prelievo, numero della riga associata, numero progressivo.

OELEN NPROG_IELEN NSEQU OARTI QRIGD_DEVAD

1009 46 1 1319 1

1009 46 2 1319 1

Ad esempio, in Fig. 19 sono riportate due letture di una calzatura ciascuna per la lista di prelievo 1009, riga 46. Entrambe sono riferite all’articolo, il cui oid è 1319.

2.4.5 Gestione generale dei documenti

La memorizzazione di ogni documento, all’interno del BMS, è divisa in due tabelle:

• Tabella della testata del documento

• Tabella delle righe del documento

La tabella della testata del documento memorizza tutte le informazioni generali per il documento e valide per tutte le righe di questo.

L’altra memorizza tutte le informazioni peculiari per ogni riga.

Se un documento può generare movimenti di magazzino, allora, a questo viene associato un record all’interno della tabella LGMOVMAG (logistica movimenti magazzini).

La struttura assai complessa della tabella LGMOVMAG è visibile in Fig. 20.

Name Type Nullable Default Comments

CSOCI VARCHAR2(4) N Codice Società CCAUS_SMAGA VARCHAR2(8) N Causale magazzino YCALE INTEGER N Anno di inserimento NPROT_DMOMA INTEGER N Num protocollo CTIPO_DMAGA VARCHAR2(4) N '0' Tipo magazzino

CMAGA VARCHAR2(8) N '0' Codice Magazzino

CUBIC VARCHAR2(24) N '0' Ubicazione

OARTI INTEGER N 0 OID art (lgartmag)

CUNMI_DMAGA VARCHAR2(4) N '0' Unità di Misura del magazzino CUNMI_DDOCU VARCHAR2(4) N '0' Unità di Misura del documento NMOLT_XCONV NUMBER(12,6) Y Moltiplicatore per conversione

Fig. 18 Tabella T_BLEVAO02

Fig. 19 Esempio di memorizzazioni delle letture ottiche

(12)

34 CUNMI_DFATT VARCHAR2(4) N '0' Unità di Misura della fattura QMOMA NUMBER Y Quantita' del movimento QMOMA_DDOCU NUMBER Y Quantita' del documento QMOMA_DFATT NUMBER Y Quantita' del documento per

fatturazione

CVALU VARCHAR2(4) N '0' Valuta

ACAMB NUMBER Y Cambio

APREZ_IVALU NUMBER Y Prezzo in valuta estera APREZ_IVALU_D NUMBER Y Prezzo in valuta estera del

documento APREZ_IVALU_F NUMBER Y

Prezzo in valuta estera del documento per fatturazione CVALU_SEURO VARCHAR2(4) N '0' EURO

ACAMB_SEURO NUMBER Y Cambio EURO

APREZ_IEURO NUMBER Y Prezzo

APREZ_IEURO_D NUMBER Y Prezzo del documento APREZ_IEURO_F NUMBER Y Prezzo del documento per

fatturazione

APREZ NUMBER Y Prezzo

APREZ_DDOCU NUMBER Y Prezzo del documento APREZ_DDOCU_F NUMBER Y

Prezzo del documento per fatturazione

PSCON_ORICA_1 NUMBER(6,3) Y PSCON_ORICA_2 NUMBER(6,3) Y PSCON_ORICA_3 NUMBER(6,3) Y PSCON_ORICA_4 NUMBER(6,3) Y PSCON_ORICA_5 NUMBER(6,3) Y PSCON_ORICA_6 NUMBER(6,3) Y ASCON_IVALU_1 NUMBER Y ASCON_IEURO_1 NUMBER Y ASCON_ORICA_1 NUMBER Y ASCON_IVALU_2 NUMBER Y ASCON_IEURO_2 NUMBER Y ASCON_ORICA_2 NUMBER Y

BANTE_SPERC VARCHAR2(1) N 'N' Ante %

DREGI_DMOMA DATE Y Data registrazione DREGI_DMOMA_E DATE Y Data reg effettiva

DCOMP_DMOMA DATE Y Data competenza

DDOCU DATE Y Data documento

CAIVA VARCHAR2(4) N '0' Codice IVA

CNUME_DCOCG_C VARCHAR2(4) Y NtrCon c/p NCOCG_DCNTR INTEGER Y Num conto c/p CTIPO_DCDCX VARCHAR2(8) N '0' Tipo CDC

CCDCX VARCHAR2(24) N '0' CDC

CIMBA VARCHAR2(4) N '0' Imballo

QCOLL INTEGER Y N. colli

CSOCI_DDERI VARCHAR2(4) N '0' Soc deriv

(13)

35 CCAUS_SMAGA_D VARCHAR2(8) N '0' Caus mag di deriv

YCALE_DDERI INTEGER N 0 Anno di deriv NPROT_DMOMA_D INTEGER N 0 Num prot di deriv CTIPO_DLOTT VARCHAR2(4) N '0' Tipo lotto

CLOTT VARCHAR2(24) N '0' Cod lotto

QSTRN NUMBER Y Quant storno

ASTRN NUMBER Y Importo storno

CSOCI_DPROV VARCHAR2(4) N '0' Soc proven CCAUS_SMAGA_P VARCHAR2(8) N '0' Caus mag di proven YCALE_DPROV INTEGER N 0 Anno di proven NPROT_DMOMA_P INTEGER N 0 Num prot di proven BCHIU_DRIGD_P VARCHAR2(1) N 'N' Chiusa riga doc proven CTIPO_DRIGD VARCHAR2(4) N '0' Tipo riga doc

CTIPO_DMAGA_2 VARCHAR2(4) N '0' Tipo mag 2 CMAGA_SSECO_2 VARCHAR2(8) N '0' Magazzino 2 CUBIC_SSECO_2 VARCHAR2(24) N '0' Ubicazione 2 CTIPO_DLOTT_2 VARCHAR2(4) N '0' Tipo lotto 2 CLOTT_SSECO_2 VARCHAR2(24) N '0' lotto 2

CTIPO_DDOCU VARCHAR2(4) N '0' Tipo docum BTIPO_DSOGG VARCHAR2(1) N 'N' Tipo Soggetto

CANAG INTEGER N 0 Soggetto

BCHIU_DRIGD VARCHAR2(1) N 'N' Chiusa riga doc BSTRN_DIMPE VARCHAR2(1) N 'N' Storno

BDEFI_OPROV VARCHAR2(1) N 'D' Definitivo o provvisorio CUNMI_SPESO VARCHAR2(4) N '0' Unità di Misura del peso

QPESO NUMBER Y Peso

CUNMI_SVOLU VARCHAR2(4) N '0' Unità di Misura del volume

QVOLU NUMBER Y Volume

CUNMI_SDIME VARCHAR2(4) N '0' Unità di Misura della dimensione QDIME_SALTZ NUMBER Y altezza

QDIME_SMAXB NUMBER Y lato maggiore base QDIME_SMINB NUMBER Y lato minore base

CALLE INTEGER N 0 Cod alle

CDIVI VARCHAR2(4) N '0' Divisione

CUSER INTEGER N 0 Utente

DAGGI DATE Y Data ultimo aggiornamento

CTIPO_DLIST VARCHAR2(4) N '0' Tipo listino

CLIST INTEGER N 0 Listino

KRAGG VARCHAR2(24) Y

NLIVE_DPREF INTEGER Y CTIPO_DCDCX_2 VARCHAR2(8) N '0' CCDCX_SSECO_2 VARCHAR2(24) N '0'

Il legame fra le informazioni del documento e il relativo movimento di magazzino è a livello delle righe del documento. La tabella delle righe e la LGMOVMAG, infatti, sono legate dai campi CSOCI, CCAUS_SMAGA, YCALE, NPROT_DMOMA. In ogni riga di un

Fig. 20 Tabella LGMOVMAG

(14)

36 documento sono presenti i campi suddetti che riportano gli estremi del movimento di magazzino associato.

2.4.6 Gestione ordini cliente

Nel paragrafo precedente è stata illustrata la modalità di gestione generale di un documento all’interno del BMS. In questo paragrafo sono presentati i dettagli riguardanti la gestione degli ordini clienti.

Le tabelle per la gestione degli ordini cliente sono:

• LGORCLTE: Testata del documento

• LGORCLRI: Righe dell’ordine

Si riporta in Fig. 22 solo la tabella delle righe del documento che è quella più importante per la gestione del magazzino.

CSOCI VARCHAR2(4) N Codice della società CCAUS_SDOCU VARCHAR2(8) N Causale del documento YCALE INTEGER N Anno di inserimento NPROT_DDOCU INTEGER N Numero protocollo NRIGA_DDOCU INTEGER N Numero riga documento CTIPO_DRIGD VARCHAR2(4) N '0'

BTIPO_DRIGD VARCHAR2(1) N 'M'

DSCAD_DRIGD DATE Y Data di consegna DSCAD_DRIGD_C DATE Y

CCAUS_SMAGA VARCHAR2(8) N '0' Causale movimento di magazzino NPROT_DMOMA INTEGER N 0

Numero di protocollo del movimento di magazzino BCHIU_DRIGD VARCHAR2(1) N 'N' Stato della riga di ordine

BVISI VARCHAR2(1) N 'N'

CGIUS VARCHAR2(4) N '0'

Fig. 21 Schema tabelle per la gestione degli ordini cliente

(15)

37 BCALC_DPROV VARCHAR2(1) N 'S'

BCONS_STAST VARCHAR2(1) N 'N' PTOLL_NQTAC INTEGER Y

CNRIG_DCLIE VARCHAR2(8) Y CANAG_SFORN INTEGER N 0 BGENE_DRORD_1 VARCHAR2(1) Y

BGENE_DRORD_2 VARCHAR2(1) Y BGENE_DRORD_3 VARCHAR2(1) Y BGENE_DRORD_4 VARCHAR2(1) Y BGENE_DRORD_5 VARCHAR2(1) Y BGENE_DRORD_6 VARCHAR2(1) Y BGENE_DRORD_7 VARCHAR2(1) Y BGENE_DRORD_8 VARCHAR2(1) Y BGENE_DRORD_9 VARCHAR2(1) Y

CALLE INTEGER N 0

CDIVI VARCHAR2(4) N '0'

CUSER INTEGER N 0

DAGGI DATE Y Data d’inserimento dell’ordine CSTAG VARCHAR2(8) Y Codice stagione di vendita

DPRZC_DDOCU DATE Y

BMARC_SSCAT VARCHAR2(1) Y Se scatolato

BATTI_SPROD VARCHAR2(1) Y Informazione sulla produzione

Ogni riga di un ordine, come già detto, ha associato un movimento di magazzino tramite i campi CCAUS_SMAGA e NPROT_DMOMA. L’anno viene omesso perché coincide con quello del documento (YCALE). Ad esempio in Fig. 23 sono evidenziate tre righe dell’ordine cliente OC/2006/141000 con i relativi movimenti di magazzino associati:

Ci sono altre due informazioni rilevanti per ogni riga di ordine date dai due campi BCHIUD_DRIGD e BATTI_SPROD. Il primo indica, se a ‘S’ che le paia in quella riga di ordine sono state spedite, se a ‘N’ che non lo sono ancora. Il secondo, invece, indica, se a ‘S’

che l’articolo ordinato è prodotto internamete all’azienda, se a ‘N’ che l’articolo è commercializzato.

CCAUS_SDOCU YCALE NPROT_DDOCU NRIGA_DDOCU CCAUS_SMAGA NPROT_DMOMA

OC 2006 141000 10 OC 2442

OC 2006 141000 20 OC 2443

OC 2006 141000 30 OC 2444

L’associazione di un movimento di magazzino ad una riga di ordine cliente può sembrare insolita, ma è da notare che, all’interno della riga di un ordine cliente, non ci sono memorizzate le informazioni riguardante il prodotto ordinato. Queste informazioni, infatti, sono state memorizzate all’interno del movimento di magazzino associato. Per la precisione all’interno di LGMOVMAG troviamo solo un riferimento all’articolo ordinato attraverso il campo OARTI, mentre il dettaglio relativo alle rimanenti informazioni identificative di una scarpa: combinazione colore, codice della forma, codice del fondo e taglia le troviamo

Fig. 22 Tabella LGORCLRI

Fig. 23 Esempio di associazione a un movimento di magazzino

(16)

38 all’interno della tabella BLMOVMAG, creata apposta per l’azienda. I campi per le suddette informazioni sono rispettivamente CCOLO, CFORM, CFOND e NTAGL.

La struttura della tabella è riportata in Fig. 24.

CSOCI VARCHAR2(4) N Codice della Società CCAUS_SMAGA VARCHAR2(8) N Causale del magazzino YCALE INTEGER N Anno di inserimento NPROT_DMOMA INTEGER N Numero protocollo NRIGA_DMOMA INTEGER N Numero riga

QMOMA NUMBER Y Quantita' del movimento QMOMA_DDOCU NUMBER Y Quantita' del documento

QMOMA_DFATT NUMBER Y

Quantita' del documento per fatturazione

APREZ_IVALU NUMBER Y Prezzo in valuta estera APREZ_IVALU_D NUMBER Y Prezzo in valuta estera del

documento APREZ_IVALU_F NUMBER Y

Prezzo in valuta estera del documento per fatturazione

APREZ NUMBER Y Prezzo

APREZ_DDOCU NUMBER Y Prezzo del documento APREZ_DDOCU_F NUMBER Y

Prezzo del documento per fatturazione

PSCON_ORICA_1 NUMBER(6,3) Y PSCON_ORICA_2 NUMBER(6,3) Y PSCON_ORICA_3 NUMBER(6,3) Y PSCON_ORICA_4 NUMBER(6,3) Y PSCON_ORICA_5 NUMBER(6,3) Y PSCON_ORICA_6 NUMBER(6,3) Y

NTAGL INTEGER Y oid taglia (bltaglie) CCOLO VARCHAR2(8) Y Codice colore CFOND VARCHAR2(8) Y Codice fondo CFORM VARCHAR2(8) Y Codice forma

CTIPO_DPRZC VARCHAR2(24) Y

A causa della presenza della divisione in taglie ogni movimento di magazzino, identificato da CCAUS_SMAGA,YCALE e NPROT_DMOMA ha tante righe, una per ogni taglia. Per identificare tali righe, perciò, in BLMOVMAG è stato introdotto il campo NRIGA_DMOMA.

Uno schema riassuntivo della tabelle per la gestione degli ordini clienti è raffigurato in Fig.

21.

Fig. 24 Tabella BLMOVMAG

(17)

39 2.4.7 Gestioni ordini di produzione

Gli articoli prodotti internamente, come già detto, si dividono in due tipologie: quelli

“classici” e quelli “fantasia”. Per quanto riguarda gli articoli “fantasia”, che sono quelli prodotti su richiesta del cliente, vengono messi in lavorazione attraverso ordini di produzione.

Ad ogni riga di ordine cliente, infatti, è associato un ordine di produzione.

Gli ordini di produzione si suddividono in due tipologie:

• OPSL: ordine di produzione semilavorato

• OP: ordine di produzione

Questa suddivisione rispecchia le due fasi principali della produzione interna. Nella prima fase si tagliano i pellami e la fodera per realizzare il tomaio della calzatura; le varie parti del tomaio, poi, attraversano una serie di passaggi intermedi e raggiungono il reparto giunteria dove vengono assemblati insieme. Queste operazioni portano alla creazione di un semilavorato. All’interno di un OPSL sono racchiuse tutte le informazioni riguardanti l’articolo da produrre: quantità per taglia , materiali necessari e operazioni specifiche fuori dallo standard.

Fig. 25 Esempio di ordine di produzione OP

(18)

40 Successivamente i semilavorati sono inseriti in un'altra catena produttiva dove si assembla insieme il tomaio e la suola. Questa seconda fase è guidata dall’OP nel quale si riportano le informazioni sui materiali necessari: tipologia della suola, del contrafforte ecc…; un esempio di OP è riportato in Fig. 25.

Anche gli ordini di produzione sono documenti per il gestionale BMS e hanno associate le seguenti tabelle:

• PRORPRTE: contiene le testate degli ordini di produzione

• PRORPRRI: contiene le righe

È riportata solo la struttura della tabella inerente alle righe in Fig. 27.

CSOCI VARCHAR2(4) N Codice società

CCAUS_SDOCU VARCHAR2(8) N Causale documento YCALE INTEGER N Anno di inserimento

Fig. 26 Schema tabelle per la gestione ordini produzione

(19)

41 NPROT_DDOCU INTEGER N Numero protocollo

NSEQU_DDOCU INTEGER N Numero della riga NRIGA_DDOCU INTEGER N

CTIPO_DRIGD VARCHAR2(4) N '0' BTIPO_DRIGD VARCHAR2(1) N 'M'

CCAUS_SMAGA VARCHAR2(8) N '0' Causale magazzino

NPROT_DMOMA INTEGER Y Numero protocollo di magazzino CRISO_SPROD VARCHAR2(8) N '0' Risorsa di produzione attuale

SEFFE DATE Y data inizio effettiva

FEFFE DATE Y

SRICH DATE Y

FRICH DATE Y

QRIGD NUMBER Y Quantita' della riga documento

QRIGD_SEVAS NUMBER Y

ACAMB_SEURO NUMBER Y Cambio EURO

CVALU_SEURO VARCHAR2(4) N '0' EURO

APREZ_IEURO NUMBER Y

APREZ NUMBER Y

BCHIU_DRIGD VARCHAR2(1) N 'N' Chiusa riga documento BPROP_SPREV VARCHAR2(1) N 'S' Prevista

TNOTA_DDOCU VARCHAR2(50) Y

CSTAG VARCHAR2(8) Y

Gli ordini di produzione sono composti da una sola riga. In maniera analoga agli ordini cliente anche per quelli di produzione c’è l’associazione di un movimento di magazzino per ogni riga. Questa associazione è realizzata, ancora, con la tabella LGMOVMAG; in questo caso, però, cambierà la causale di magazzino da OC a OP. Inoltre, come negli ordini cliente, le caratteristiche identificative della scarpa, a meno dell’articolo, sono memorizzate in BLMOVMAG.

Una volta che la calzatura è stata versata nei magazzini del prodotto finito l’ordine di produzione è chiuso mettendo il campo BCHIUD_DRIGD a ‘S’.

L’associazione tra ordine di produzione e la riga di ordine cliente è realizzata attraverso la tabella PROPXORC la cui struttura è evidenziata in Fig. 28. In questa tabella per ogni ordine produzione sono riportate le coordinate della riga di ordine cliente associata. Uno schema delle tabelle coinvolte nella gestione degli ordini di produzione è visibile in Fig. 26.

CSOCI VARCHAR2(4) N Codice della società CCAUS_SORCL VARCHAR2(8) N Causale ordine cliente YCALE_SORCL INTEGER N Anno ordine cliente

NPROT_DORCL INTEGER N Numero protocollo ordine cliente NRIGA_DORCL INTEGER N Numero riga ordine cliente

Fig. 27 Tabella PRORPRRI

(20)

42 CCAUS_SORPR VARCHAR2(8) N Causale ordine produzione

YCALE_SORPR INTEGER N Anno ordine produzione

NPROT_DORPR INTEGER N Numero protocollo ordine produzione NSEQU_DORPR INTEGER N

QRIGD_XRIGD_P NUMBER Y

BCHIU_DRIGD_P VARCHAR2(1) N 'S' Chiude riga doc ordine cliente TNOTA_DDOCU VARCHAR2(50) Y

BCHIU_DRIGD VARCHAR2(1) N 'N' Fig. 28 Tabella PROPXORC