Visualizza post

Questa sezione ti permette di visualizzare tutti i post inviati da questo utente. N.B: puoi vedere solo i post relativi alle aree dove hai l'accesso.


Post - sotema

Pagine: [1] 2 3 ... 32
1
Programmazione / Re:Sviluppo Gestionale Rubinetto Felice
« il: 01 Febbraio 2016, 17:06:03 »
Ciao Sotema,
sono bloccato, ho trovato un'incongruenza fra la tabella clienti e la tabella sedi.
La tabella sedi ha come chiave primaria idsede come può essere anche chiave esterna lato molti per la tabella clienti?  :rolleyes:

 :ciao:
Dove sta il problema?
La chiave esterna per la tabella clienti è un vincolo referenziale; ti vieta di assegnare per un Cliente una Sede che non esiste nella tabella Sedi. Se poi volessi cancellare un Cliente (cosa per altro da evitare quasi sempre) ti permette di cancellarne in automatico (ON DELETE CASCADE) anche tutte le sedi corrispondenti.
 :ciao:

2
Programmazione / Re:Sviluppo Gestionale Rubinetto Felice
« il: 30 Gennaio 2016, 23:23:20 »
Buonanotte.
Per quando ti svegli ho preparato un semplice schema per illustrarti il mio punto di vista. Perdona se non ho utilizzato i nomi tabella/campi concordati, ma l'ho preparato al volo.
La tabella Clienti eredita la tabella Aziende e tramite la tabella sedi crea una relazione molti-a-molti con la tabella persone.

3
Programmazione / Re:Sviluppo Gestionale Rubinetto Felice
« il: 30 Gennaio 2016, 22:15:29 »
Una impresa detiene una ed una sola Ragione Sociale. Indipendentemente dal numero di Sedi, il termine corretto è Unità Locali, che verranno utilizzate per l'esercizio dello Scopo Sociale. La Ragione Sociale viene depositata presso la Camera di Commercio (CCIAA) della provincia dove risiede la Sede Legale; la sede legale può essere una Unità Locale dell'impresa ma anche uno Studio Legale, Studio Commercialista, residenza del Titolare o del Rappresentante Legale.  All'atto della registrazione dell'impresa viene assegnato un Numero di Partita Iva ed un Codice Fiscale (nel caso di Società di Persone o Società di Capitali spesso PIVA e CF coincidono). Ogni Sede viene poi identificata con un proprio Numero di Repertorio Amministrativo (il famoso REA).

Tre tabelle servono per tenere separati i Clienti dai Fornitori e per evitare campi nella tabella anazie, che sarebbero molto spesso impostati a NULL.  Immagina un SELECT * FROM anacli WHERE prvcli = 'RM' che ti riportasse anche i fornitori. Inoltre ti semplifica la gestione deglimordini dei clienti, la gestione dei preventivi e la gestione delle commesse.



4
Programmazione / Re:Sviluppo Gestionale Rubinetto Felice
« il: 30 Gennaio 2016, 19:33:41 »
Ciao Gianluigi,
spiacente, ma concordo con Berseker79; da come hai disegnato le relazioni in  "RelazioniAziende(20-01)", sembrerebbe che un potenziale cliente possa avere più ragioni sociali, cosa praticamente impossibile. Mentre è possibile che un Cliente abbia diverse sedi. Ne consegue che la relazione deve essere, come detto da Berseker79, uno (anazie) a molti (anacli, anafor, anavet).

Io mi spingerei anche oltre inserendo nella tabella anazie i soli dati fiscali del cliente, rasaz, cofaz, pivaz e webaz, malaz (di solito tutte le aziende hanno una mail generica del tipo info@nomeazienda.dominio); nella tabella anacli inserirei i campi codcli (codice cliente), idazie per la relazione con anazie e il campo idsed come relazione alla tabella ansedi, il campo per identificare il listino associato (idlist?). La tabella ansedi conterrà i campi della sede: indirizzo, comune, cap, provincia, nazione, telefono, fax... ed un campo boolean, impostato a true se si tratta della sede legale. La tabella anaper, tramite i campo idsed e idazie farà il collegamento tra le persone, la sede e l'azienda.
Identico ragionamento per i fornitori.
 :ciao:

5
Programmazione / Re:Sviluppo Gestionale Rubinetto Felice
« il: 24 Gennaio 2016, 16:55:50 »
Rileggendo quanto ho scritto ieri sera mi chiedo quanto avesse bevuto prima...
Chiedo perdono a tutti ed in particolare a te Gianluigi per quanto scritto.
Una tabella eredita tutti i campi della tabella genitrice ma NON ne eredita i vincoli e la Chiave Primaria. L'utilizzo più frequente è prorpio quello di evitare duplicazioni di dati creando tabelle senza campi per la maggior parte nulli.
Ti faccio un esempio pratico. Immagina di dover catalogare i prodotti di un laboratorio che venda articoli di terzi e articoli auto prodotti. Potresti usare la seguente struttura.

Prodotti
- Codice
- Descrizione
- Prezzo
...

Terzi (eredita Prodotti)
- Fornitore

l'inserimento dei dati avverrà nel modo seguente:
INSERT INTO prodotti (codice, descrizione, prezzo) VALUES (1, 'Tazza ceramica', 12.3);
INSERT INTO prodotti (codice, descrizione, prezzo) VALUES (2, 'Piatto Fondo', 7.16);

INSERT INTO terzi (codice, descrizione, prezzo, fornitore) VALUES (3, 'Tazza vetro', 2.71,'Vetroglass');

le interrogazioni saranno eseguite:
SELECT * FROM prodotti; per l'elenco di tutti i prodotti

SELECT * FROM ONLY prodotti per l'elenco dei soli articoli auto prodotti.

SELECT * FROM terzi; per l'elenco degli articoli rivenduti ed i loro fornitori.

Fermo restando che entrambe le tabelle devono avere una loro chiave primaria.

Detto questo quello che risulta inutile, penso fosse quello che intendeva anche Berseker7, sono le relazioni idcli, idfor, idvet nella tabella anazie poichè esiste già la relazione idazi. Nel caso specifico delle tabelle ereditate anche la relazione idazie è superflua, se non dannosa.
Come sempre si tratta di decidere quale sia la strada migliore da seguire.
 :ciao:

6
Programmazione / Re:Sviluppo Gestionale Rubinetto Felice
« il: 23 Gennaio 2016, 21:25:38 »
Tu e Sotema intendete soltanto rovesciare il concetto? Evitare di avere tanti campi vuoti (se un anazie è cliente, fornitore vettore e organizz. saranno vuoti), è così?
Quello che io, e credo Berseke79, intendo dire è che non serve una chiave primaria nelle tabelle clienti, fornitori e vettori, in quanto hai già la chiave primaria in anazie. Proprio per questo motivo ti accennavo alle tabelle ereditate. Una tabella figlia eredita tutti i campi dalla tabella madre; per cui ne deriva che se la tabella clienti eredita anazie, ne eredita anche la chiave primaria. In soldoni:
la tabella anazie contiene i dati:
Ragione Sociale, Indirizzo, Comune....
la tabella anacli contiiene i dati
Codice Cliente, listino associato, Vettore preferito, modalità pagamento (Ricevuta bancaria, bonifico, contrassegno...) e tutti quei campi che sono peculiari di un cliente.
In questo modo non avrai campi vuoti nella tabella clienti. La relazzione sarà stabilita tramite il campo idazi.
Sono consapevole che nel contenuto spazio di un post è difficile esprimere in modo esaustivo le idee, se mi avanza del tempo domani ti preparo un file con una struttura ridotta di db da caricare sul tuo server, in modo da illustrarti in pratica l'dea.
 :ciao:

7
Programmazione / Re:Sviluppo Gestionale Rubinetto Felice
« il: 21 Gennaio 2016, 14:44:22 »
Purtroppo ancora adesso dopo averne parlato con te non ho chiaro se REA debba essere memorizzato solo per la nostra organizzazione o anche per le altre aziende: Clienti, fornitori ecc.
Allora facciamo luce...
Numero di iscrizione al Registro Imprese (RI): viene assegnato dalla Camera di Commercio (CCIAA) della provincia in cui risiede la Sede Legale di un' impresa; ogni impresa detiene uno ed un solo numero di Registro Impresa. Si tratta di un numero progressivo preceduto dalla sigla della CCIAA che lo ha rilasciato: TO 125687 - CT 99853168...
Dal 6 dicembre 2000 il numero RI è stato dismesso e sostituito dal Codice Fiscale  (non la Partita Iva) dell'impresa.

Numero di Repertorio Economico ed Amministrativo (REA): viene assegnato dalla Camera di Commercio (CCIAA) della provincia in cui risiede una Unità Locale dell'impresa sia questa un ufficio o un magazino Risulta quindi la seguente organizzazione:

Rubinetto Felice SrL

Sede Legale
Via della Cascata, 16
35121 Padova PD
PI 12865487139
Numero CCIAA PD 5541298
Numero REA 55429783


Filiale di MIlano
Via dei Fontanili, 12
20141 Milano MI
Numero CCIAA PD 5541298
Numero REA 653294


Deposito Merci
Via delle Termofili, 45
35031 Abano Terme Padova
Numero CCIAA PD 5541298
Numero REA 55429783


Deposito Merci
Via Pasterngo, 1
40123 Bologna
Numero CCIAA PD 5541298
Numero REA 882163


Tieni presente che è fatto obbligo di indicare su tutti i documenti fiscali il Numero RI, mentre il Numero REA può essere omesso.
Ai fini del nostro progetto è indispensabile memorizzare il  Numero RI e tutti i Numero REA solo per Rubinetto Felice.
Spero di averti chiarito le idee; nel fine settimana do una occhiata alle nuove relazioni.
Ciao.

8
Programmazione / Re:Sviluppo Gestionale Rubinetto Felice
« il: 20 Gennaio 2016, 00:07:53 »
Ciao Sotema,
scusa il ritardo della risposta, ma sono dovuto uscire e rientro solo adesso.
Come vedi anche io non scherzo coi tempi...
Nel mio ultimo post dicevo che prendevo a  riferimento il diagramma Relazione Aziende 2

mi appare oscuro il motivo di inserire idcli al posto di idtcl (ID Tipologia Cliente) che avrebbe dovuto catalogare i clienti in base all'importanza e che potrebbe essere utile per la scontistica.
Non avevo intuito che la t in idtcl stava per 'tipo', pensavo ad un errore di scrittura.

Ti ripeto la mia perplessità circa la tabella anamag da cambiare in anasedi sembra una ripetizione della tabella anazie quali campi reputi indispensabili in essa? Quali superflui?
Se lo scopo della tabella anasedi è catalogare le varie sedi (siano esse magazzini o no) delle aziende contenute in anazie, allora dovrai registrarvi i dati fiscali di ciascuna sede;  se poi la sede di cui parliamo è un filiale di Rubinetto Felice il Numero REA, che sarà differente da quello della sede centrale qualora la sede sia residente in una provincia diversa, deve necessariamente essere registrato poiché deve comparire nei documenti fiscali emessi dalla filiale. Per chiarire il concetto :

Spedizione a Sede o Magazzino  di un cliente
Sui documenti fiscali dovranno apparire:
Per Rubinetto Felice
Ragione Sociale
Indirizzo Sede Legale (Via - Comune - CAP - Provincia)
Codice Fiscale e Partita IVA (qualora differenti devono apparire entrambi)
Numero REA
Numero CCIAA

Per il Cliente
Ragione Sociale
Indirizzo Sede Legale (Via - Comune - CAP - Provincia)
Codice Fiscale e Partita IVA (qualora differenti devono apparire entrambi)
Indirizzo di spedizione Merce (se diverso dall' indirizzo della sede legale)

I dati relativi alle sedi diverse dalla Sede Legale, li metti in anasedi, per non avere la tabella anazie piena di campi nulli.
Ovviamente i dati delle Sedi Legali saranno in anazie.

Per quale motivo non è sufficiente il codice azienda (idazi)?
Se ti riferisci ad ulagg e utagg devono comparire in anacli per eventuali attività di audit. (chi ha fatto cosa?)

Attento, la gestione dei listini non è roba da ridere... ;D
Magari affronteremo il tema in futuro (la moglie si sta lamentando....)
Ciao

9
Programmazione / Re:Sviluppo Gestionale Rubinetto Felice
« il: 18 Gennaio 2016, 18:47:21 »
Ciao Gianluigi,
perdonami se qualche volta perdo il filo, i tuoi richiami a quanto detto nei primi post è fondamentale. Purtroppo il tempo da dedicare al forum viene ritagliato tra i troppi impegni.
Cerco di essere più preciso possibile, ma sono convinto che ne usciremo vivi.
Il diagramma Relazione Aziendale 2 mi sembra quello meglio concepito, lavorerei su quello, apportando le seguenti modifiche:
1. Rinominare la tabella anamag in anasedi
2. Nella tabella anasedi inserire il campo reased
3. In tutte le tabelle eliminare il campo oragg e rinominare il campo datag in ulagg (timestamp)
4. Nella tabella rinominerei il campo idctl in idcli
5. I campi ulagg e utagg devono comparire in tutte le tabelle. Ma non sono delle relazioni.
6. La gestione dei vettori la farei in questo modo:
    La tabella principale anavet che contiene, tramite anazie, l'anagrafica
    Una tabella separata per la gestione della tipologia: locale, regionale, nazionale, espresso...
    Una tabella separata per la gestione dei tempi e delle condizioni economiche; spesso i corrieri offrono tabelle di costo in base al peso, ai volumi di lavoro ecc.
Ovviamente se la funzione di anacli, anafor e anavet è quella di gestire i campi che differenziano cade il discorso sulla eredità.

Le relazioni che ritengo superflue sono quelle inserite nel diagramma Nuova Relazione Aziende dove hai inserito in anazie i campi idcli, idfor, idvet.

Sotema


10
Programmazione / Re:Sviluppo Gestionale Rubinetto Felice
« il: 18 Gennaio 2016, 14:00:23 »
Ciao Gianluigi,
penso ti stia ingarbugliando.
Che senso ha porre dei vincoli nella tabella anazie verso anacli, anafor,... quando queste sono già legate ad anazie tramite idazi? Non so perché avevi pensato alle tabelle anacli e anafor, forse per separare nettamente clienti e fornitori? IN questo caso ti suggerisco di inserire i campi codcl (codice cliente) e codfo (codice fornitore) dati da stampare obbligatoriamente sui documenti fiscali. Se poi predisponi una tabella listini (altra bella storia), potresti collegarla ad anacli per gestire le condizioni di vendita. La tabella anavet potresti popolarla con i campi relativi a Luoghi di consegna (potrebbe essere un corriere locale, regionale o nazionale) ed i relativi costi; la qualcosa potrebbe tornare utile in sede di preventivo. Anche i tempi di presa e consegna possono differire da un vettore all'altro.

Non comprendo invece lo scopo della tabella anazia.

seguire i risultati di calcio mentre si valuta un gestionale forse non è così conveniente.

sarà per questo che non mi interessa il calcio?
 ;D

Propongo anche l'ennesima possibile relazione, non mi convince in quanto i magazzini non credo abbiano REA, Codice Fiscale, sito web...
 :ciao:

Le sedi decentrate, siano esse magazzini o uffici, detengono un diverso Numero REA se risiedono in una provincia diversa dalla sede legale, facendo quindi capo ad una differente CCIAA.

11
Programmazione / Re:Sviluppo Gestionale Rubinetto Felice
« il: 18 Gennaio 2016, 12:05:37 »
Ciao Gianluigi,
circa i nomi dei campi procedi pure con la logica sinora utilizzata; spesso nelle risposte ai post non bado alla precisione, è un difetto che mi porto fin dall'antichità.

Per quanto riguarda la tabella ansedi, dal diagramma Relazioni Aziende 2, mi pare di capire che la tabella anaper si collega alla tabella anamag attraverso le tabelle anacli, anafor, anavet, anazi; quindi sarai sempre in grado di associare la/le persone ad una aienda. Ci saranno aziende con più addetti di magazzino e aziende con un solo addetto. Dalla tabella mansio potrai selezionare gli addetti di magazzino.

Riguardo le imprese a conduzione famigliare anch'esse hanno l'obbligo di aprire una Partita Iva, qundi non vedo l'ostacolo.

Se ho male inteso ti prego di chiarirmi i tuoi dubbi.

EDIT:
ho scaricato la tabella ansed. Mi chiedo perché l'hai completamente riscritta. la struttura di anamag era corretta, poco importa che la sede sia un magazzino o uffici, resta pur sempre una sede.

Sotema

12
Programmazione / Re:Sviluppo Gestionale Rubinetto Felice
« il: 17 Gennaio 2016, 00:40:58 »
@Sotema,
forte il suggerimento rivolto agli oggetti, era mia intenzione iniziale che progettassimo un database generico adatto a qualunque marca di database come raccomanda Hernandez, in effetti non ha senso visto che abbiamo scelto PostgreSQL e allora ti chiedo ma poi con SQL come si interroga una tabella ereditata?

semplicemente con SELECT. Poniamo che la tabella anacli eredita la tabella anazie, ebbene con l'istruzione:
Codice: [Seleziona]
SELECT rasaz, indaz, idtcl FROM anacli ;
estrai i campi da entrambe le tabelle.
Come si disegna nello schema?
vedi allegato, nello schema studente, disoccupato e lavoratore ereditano persona.
A proposito di campi dimenticati:
Per l'azienda aggiungo un campo registro imprese?
Il Numero Registro Imprese corrisponde al Codice Fiscale (non la partita iva a meno che questa sia uguale al CF); la modifica è stata introdotta dal DPR 586 del 14 dicembre 1999. Aggiungerei invece il campo REA (Numero di Repertorio delle notizie Economiche e Amministrative del Registro delle Imprese). Mentre il numero RI è unico a livello nazionale e assegnato dalla CCIAA della provincia in cui risiede la sede legale, il numero REA è diverso per ogni provincia/CCIAA in cui apri una sede/unità locale. Di conseguenza apporterei le seguenti modifiche:
1. La tabella anamag deve essere rinominata in ansedi
2. La tabella ansedi deve contenere il campo nurea

Circa la problematica della Ragione Sociale aggiuntiva... è la prima volta che lo sento. Mi informo.


13
Programmazione / Re:Sviluppo Gestionale Rubinetto Felice
« il: 16 Gennaio 2016, 20:11:29 »
Ciao Gianluigi.
Innanzitutto complimenti per la mole di lavoro svolto, immagino dedicandogli molto del tuo tempo libero.
Ho dato un'occhiata veloce a quanto da te prodotto e vorrei segnalare solo un paio di cose. Visto che usi una tabella principale Aziende cui associ le anagrafiche vettori, clienti, fornitori ed azienda perché non utilizzare le tabelle ereditate? La tabella principale sarà ANAZIE e le anagrafiche ereditano tutti i campi della tabella padre, in aggiunta ciascuna di esse avrà un campo Codice che ti permette di identificare la singola anagrafica. Ad esempio la tabella anacli conterrà il campo codcl (codice cliente), la tabella anafor il campo codfo...

Per quanto riguarda invece la gestione degli aggiornamenti invece dei campi datag ed oragg utilizzerei un solo campu ulagg di tipo timestamp.

Spero comunque di trovare un poco di tempo domani per approfondire l'analisi.

A presto.  :ok:

14
Programmazione / Re:Sviluppo Gestionale Rubinetto Felice
« il: 01 Dicembre 2015, 21:09:48 »
Ciao Gianluigi,
perdona il prolungato silenzio, ma il periodo pre natalizio è per me il peggiore dell'anno.
Riguardo al metodo che suggerisci a me va bene, tenendo conto che giochi al tempo stesso il ruolo del cliente e dello sviluppatore. Non sentirti frustato se non hai ottenuto risposte, vedrai che arrivano.

 :ciao:

15
Programmazione / Re:Sviluppo Gestionale Rubinetto Felice
« il: 24 Novembre 2015, 21:59:05 »
Ciao Sotema,
ieri ero stanco e non mi è venuto in mente che avrei potuto (dovuto) riavviare.
Stamattina pare proprio funzionare.
Non mi ero neanche accorto che psql mi parlava in italiano, figo.  8)
 :ciao:
I file di configurazione vengono letti all'avvio del server, per cui ogni modifica apportata, affinché diventi effettiva richiede che sia letta dal server. Puoi anche usare il comando: sudo service postgresql reload che non riavvia il server ma lo forza a rileggere la configurazione.

Pagine: [1] 2 3 ... 32