Creazione database access lavorazioni ufficio

di il
30 risposte

30 Risposte - Pagina 2

  • Re: Creazione database access lavorazioni ufficio

    Ildono ha scritto:


    Grazie mille del supporto, allora circa il cosa si fa nell'ufficio , noi siamo uno degli step di accettazione delle richeste di credito, le pratiche(singole lavorazioni in merito alla valutazione di un richiedente di credito ovvero prestiti diciamo) arrivano su un cruscotto, gia dal primo tep di lavorazione del primo ufficio che valuta ,poi diventa visibile anche a noi quando arriva al nostro ufficio .
    le voci della tabella pratiche sono:
    data flusso, data cruscotto,nome, id cliente, tipo di prestito,data presa in carico da operatore,data fine lavorazione pratica,data scadenza pratica (ogni pratica resta attiva 20 gg dalla data cruscotto), esito,note, operatore.
    solo alcune non vengonon ereditate dal copia e incolla dal cruscotto, ovvero data presa in carico, data fine, esito, note e operatore.
    Per la tabella degli operatori immagino
    id e 20 cognomi per ogni record. o un record con una tendina?
    dimmi se sono stato chiaro grazie ancora!!
    Per me il "cruscotto" ricorda soltanto l'automobile, poi non capisco cosa vuol dire nel tuo gergo professionale.
    Sinceramente ignoro tutti i passaggi/step di cui parli e prendo per buoni tutti i campi di Pratiche.
    Secondo quanto ci ho capito fin qui, rivedrei l'assetto tabelle così:

    Clienti
    IDCliente (PK)
    Cognome
    Nome
    Indirizzo
    ...altri campi tipicamente anagrafici...

    Operatori
    IDOperatore (PK)
    Operatore (solo il Cognome)

    TipiPrestiti
    TipoPrestito (testo breve, PK)

    Pratiche
    IDPratica (PK)
    DataFlusso
    DataCruscotto
    Nome (o NomePratica...non ho capito se ha questo significato)
    IDCliente (FK)
    TipoPrestito (FK)
    DataPresaIncarico
    DataFineLavorazionePratica
    DataScadenzaPratica
    Esito
    Note
    IDOperatore (FK)

    Relazioni:
    Clienti.IDCliente uno-a-molti Pratiche.IDCliente
    Operatori.IDOperatore uno-a-molti Pratiche.IDOperatore
    TipiPrestiti.TipoPrestito uno-a-molti Pratiche.TipoPrestito

    I significati di PK=PrimaryKey (chiave primaria), FK=ForeignKey (chiave esterna). Generalmente una PK è di tipo "numerazione automatica", mentre la corrispondente FK è "numerico". Nel caso particolare di TipoPrestito, trattandosi di una tabella monocampo, si può anche usare un campo di tipo "testo breve" per PK, idem il corrispondente FK. Se ciò non ti piace, progetta i campi di relazione sempre con ID, secondo la dottrina standard da manuale.
  • Re: Creazione database access lavorazioni ufficio

    @Osvaldo ma se ci pensi c'e' un problema di fondo:
    @Ildono deve avere GIA' un database da qualche parte. NON DEVE progettare un nuovo database, al piu' estendere uno che c'e' gia'.
    Se no che fa, reinserisce per l'ennesima volta gli stessi dati che sono stati inseriti in fase di accettazione della pratica? Con il rischio di disallineamenti?

    E se c'e' un utente che ha gia' pratiche in corso? Con un db separato hai solo informazioni locali, e non hai accesso allo storico.

    Senza nulla togliere alla buona volonta' di @Ildono, ma forse la strada che si state per intraprendere potrebbe risultare parecchio accidentata.
  • Re: Creazione database access lavorazioni ufficio

    migliorabile ha scritto:


    Ildono deve avere GIA' un database da qualche parte. NON DEVE progettare un nuovo database, al piu' estendere uno che c'e' gia'.
    Io leggo dal titolo del thread "Creazione database..."

    migliorabile ha scritto:


    Se no che fa, reinserisce per l'ennesima volta gli stessi dati che sono stati inseriti in fase di accettazione della pratica? Con il rischio di disallineamenti?
    E se c'e' un utente che ha gia' pratiche in corso? Con un db separato hai solo informazioni locali, e non hai accesso allo storico.
    Questo aspetto a me sfugge perché non conosco passo passo cosa succede nell'azienda di Ildono. Per me starebbe bene l'idea di uno storico, ma non ho capito come si sviluppa. Fornendo quella tabella Pratiche con tutti quei campi Data, mi immagino che l'utente prima di inserire un nuovo record si deve preoccupare se Pratiche.IDCliente esiste già e controllare come sta la situazione (purtroppo) "in orizzontale".
    Altrimenti Ildono deve fornire altri dettagli e spiegazioni.
  • Re: Creazione database access lavorazioni ufficio

    @Osvaldo, anche se @Ildono ha scritto "Creazione database ..." visto le domande, potrebbe non aver chiaro come affrontare il problema.
    E' vero, deve fornire ulteriori spiegazioni, ma noi dobbiamo anche indirizzarlo, facendogli le domande giuste
  • Re: Creazione database access lavorazioni ufficio

    Ragazzi grazie ancora,
    cerco di essere più chiaro:
    ad oggi questo"DB" è un file excel, per ogni colonna ci sono le voci che vi ho elencato prima, essendo un excel è facilmente "sput****bile quindi si è pensato di ricorrere ad access. Sicuramente potrei partire caricando lo storico esistente su excel ma preferirei costruire la struttura e poi magari inserirlo con una query alla fine, giusto prima di renderlo disponibile all'ufficio.
    A livello operativo attuale, un collega stabilito, va su un applicativo (cruscotto), dove c'è una mascherina con elencate queste "pratiche", come ho già detto a noi le pratiche diventano visibili solo in seguito, poichè non siamo il primo step autorizzativo ecco il perchè del campo "data flusso" (quando il mio ufficio vede la pratica) e del campo data cruscotto (quando è stata carica nell'applicativo e resa disponibile all'ufficio che ricopre lo step autorizzativo prima del nostro).
    Ogni mattina in quasto applicativo sono visibili le pratiche che ancora non sono state autorizzate e quelle nuove, quindi il mio collega copia e incolla su excel le info della mascherina (che nel nostro file attuale ci danno automaticamente delle info valorizzando i campi data flusso, data cruscotto, id , nominativo cliente(ci interessa solo quello), prestito (SI/NO),nome proponente(ufficio che lavora la pratica prima di noi) e data scadenza (è 20 gg dal data cruscotto)).
    Fatto ciò per n pratiche (records) inserisce la data presa in carico e operatore(circa 2 a testa ne assegna).
    Ogni operatore fa quello che deve e riempie i campi restanti illustrati prima e cosi via ogni giorno.
    Ora fermo che spesso "scompaiono records e che nessuno deve poter rimuovere una carica a lui assegnata", si è deciso di passare ad access.
    rispetto ad oggi, immagino cambierà il caricamento sul db che avverrà con query di accodamento e non copia e incolla.
    Cambierà che con la query si popoleranno data flusso, data cruscotto, id , nominativo cliente, prestito (SI/NO),nome proponente(ufficio che lavora la pratica prima di noi) e data scadenza (è 20 gg dal data cruscotto) diventando non modificabili a nessuno, a differenza della data presa in carico e operatore che è inseribile solo dall'assegnatore.
    Visto che l'assegnazione avviene ogni giorno, non vorremmo che l'assegnatore veda ogni mattina tutte le n-mila pratiche della tabella attraverso la maschera (che possono sempre essere analizzate con report) ma che vedesse al di là del giorno di "accodamento su access" solo quelle da assegnare.
    in seconda instanza all'atto dell'assegnazione vorremmo che vedesse per ogni operatore(profilato con cognome e basta) quante ne ha in carico.
    I singoli operatori andranno su una maschera delle pratiche assegnate e inseriranno data fine, esito(approvato rifiutato), note(testo libero).
    Ferma la tabella delle "pratiche" già detta, una con i cognomi dei colleghi, quante altre ne devo creare?
    grazie della pazienza e soprattutto della comprensione!!
  • Re: Creazione database access lavorazioni ufficio

    O forse per i colleghi serve una tabella per ognuno con le stesse colonne della tabella principale per avere la maschera con "lo stato di carico di ciascuno"? e poi impostare una relazione? mi sto forse confondendo con la casella combinata con elenco valori per i cognomi?
    vorrei farlo più semplice e linearepossibile
  • Re: Creazione database access lavorazioni ufficio

    Quest'ultimo post raggruppa troppe domande per essere risolte in un unico thread. Va bene che hai voluto dare più spiegazioni, in quanto te le abbiamo richieste, ma per ora devi fermarti alla fase di PROGETTAZIONE tabelle.
    Che dire: si può semplificare la tabella Pratiche ai soli campi essenziali:
    IDPratica
    NomePratica
    IDOperatore

    poi ci può stare una tabella StoriciPratiche o DettagliPratiche con i campi:
    IDSP o IDDP (numerazione automatica, PK)
    Data
    TipoPassaggio
    IDPratica (FK)

    e magari una tabella
    TipiPassaggi
    TipoPassaggio (PK)

    Relazioni:
    Pratiche.IDPratica uno-a-molti DettagliPratiche.IDPratica
    TipiPassaggi.TipoPassaggio uno-a-molti DettagliPratiche.TipoPassaggio

    Tutto questo presupponendo che una Pratica venga SEGUITA sempre dallo stesso Operatore...

    Spero che ora tu cominci a cogliere il senso dei campi chiave e delle relazioni che ti appaiono arabo dagli esempi dei manuali. Devi scrostarti/abolire ogni logica di Excel e pensare attraverso PIU' tabelle RELAZIONATE.
  • Re: Creazione database access lavorazioni ufficio

    Ildono ha scritto:


    O forse per i colleghi serve una tabella per ognuno con le stesse colonne della tabella principale per avere la maschera con "lo stato di carico di ciascuno"? e poi impostare una relazione? mi sto forse confondendo con la casella combinata con elenco valori per i cognomi?
    vorrei farlo più semplice e linearepossibile
    Ripeto, aspetta...anzi resetta adesso questa domanda e riproponila in un nuovo thread. Meglio spezzettare più problematiche su più thread e non fare un polpettone disordinato in un'unica (troppo) lunga discussione.

    La casella combinata raramente la si imposta su Elenco valori. Nel caso di IDOperatore, essa deve guardare i valori dalla tabella Operatori sul campo IDOperatore. Poi ti devi ingegnare con le larghezze colonne...se ne è già parlato spesso in altri thread...
  • Re: Creazione database access lavorazioni ufficio

    Ildono ha scritto:


    Ragazzi grazie ancora,
    cerco di essere più chiaro:
    ad oggi questo"DB" è un file excel, per ogni colonna ci sono le voci che vi ho elencato prima, essendo un excel è facilmente "sput****bile quindi si è pensato di ricorrere ad access. Sicuramente potrei partire caricando lo storico esistente su excel ma preferirei costruire la struttura e poi magari inserirlo con una query alla fine, giusto prima di renderlo disponibile all'ufficio.
    A livello operativo attuale, un collega stabilito, va su un applicativo (cruscotto), dove c'è una mascherina con elencate queste "pratiche", come ho già detto a noi le pratiche diventano visibili solo in seguito, poichè non siamo il primo step autorizzativo ecco il perchè del campo "data flusso" (quando il mio ufficio vede la pratica) e del campo data cruscotto (quando è stata carica nell'applicativo e resa disponibile all'ufficio che ricopre lo step autorizzativo prima del nostro).
    Ogni mattina in quasto applicativo sono visibili le pratiche che ancora non sono state autorizzate e quelle nuove, quindi il mio collega copia e incolla su excel le info della mascherina (che nel nostro file attuale ci danno automaticamente delle info valorizzando i campi data flusso, data cruscotto, id , nominativo cliente(ci interessa solo quello), prestito (SI/NO),nome proponente(ufficio che lavora la pratica prima di noi) e data scadenza (è 20 gg dal data cruscotto)).
    Fatto ciò per n pratiche (records) inserisce la data presa in carico e operatore(circa 2 a testa ne assegna).
    Ogni operatore fa quello che deve e riempie i campi restanti illustrati prima e cosi via ogni giorno.
    Ora fermo che spesso "scompaiono records e che nessuno deve poter rimuovere una carica a lui assegnata", si è deciso di passare ad access.
    rispetto ad oggi, immagino cambierà il caricamento sul db che avverrà con query di accodamento e non copia e incolla.
    Cambierà che con la query si popoleranno data flusso, data cruscotto, id , nominativo cliente, prestito (SI/NO),nome proponente(ufficio che lavora la pratica prima di noi) e data scadenza (è 20 gg dal data cruscotto) diventando non modificabili a nessuno, a differenza della data presa in carico e operatore che è inseribile solo dall'assegnatore.
    Visto che l'assegnazione avviene ogni giorno, non vorremmo che l'assegnatore veda ogni mattina tutte le n-mila pratiche della tabella attraverso la maschera (che possono sempre essere analizzate con report) ma che vedesse al di là del giorno di "accodamento su access" solo quelle da assegnare.
    in seconda instanza all'atto dell'assegnazione vorremmo che vedesse per ogni operatore(profilato con cognome e basta) quante ne ha in carico.
    I singoli operatori andranno su una maschera delle pratiche assegnate e inseriranno data fine, esito(approvato rifiutato), note(testo libero).
    Ferma la tabella delle "pratiche" già detta, una con i cognomi dei colleghi, quante altre ne devo creare?
    grazie della pazienza e soprattutto della comprensione!!
    A me di tutta sta pappardella non è chiaro:
    1. Una Pratica osserva "tutti quegli" steps (chiamiamoli 1,2,3,4,5,6,7,8) tutti in fila, oppure può capitare che una Pratica veda evolversi con i soli steps 1,3,5,8 e poi va in porto lo stesso, in un'altra ancora possono capitare gli steps 1,2,7?
    2. Il fatto che l'Operatore "Rossi" non veda lo step 1, ai fini del database cosa importa? Quando tu avrai noto lo step 2, evidentemente contabilizzerai 2 steps (1 e 2).
    3. Devi chiarirmi se una stessa Pratica viene trattata sempre dallo stesso Operatore, oppure un Operatore il giorno 20/11/2017 tratta 5 Pratiche e aggiunge 5 steps?
    4. A me non convince molto il fatto che molti Operatori mettano mano alle maschere del database e poi non devono sapere lo storico di una Pratica. Penso che tutto questo farraginume dovrebbe essere gestito da un solo utente "database/digitatore" che traccia tutte le informazioni passo passo indicando anche chi è l'Operatore...Qua vorrei molta chiarezza perché non ci arrivo.
    5. Se tu descrivessi 2-3 esempi VERI, io riuscirei a comprendere meglio il tuo ambito lavorativo e di conseguenza il significato dei campi...perché non capisco se si tratta di una fabbrica, una banca, un boh!!!!!
    6. Parli di Operatori in genere, poi parli di un Assegnatore. Quest'ultimo è un Operatore anch'egli? Se sì, perché gli dai un nome diverso?
  • Re: Creazione database access lavorazioni ufficio

    1) immagina che ci sia una matrice con 2 ruoli decisionali, ogni ruolo decisionale corrisponde ad uno step valutativo, categoricamente si svolgono in sequenza quindi c'è step 1 (ufficio 1)e step 2 (ufficio mio) che sull'applicativo (cruscotto) hanno come output nota 1 (autorizzo a proseguire o respingo (da parte di Ufficio 1)) e nota 2 (accettato o rifiutato (da parte dell' Ufficio mio). Quindi ricapitolando se una pratica è arrivata da noi ,ci saranno sempre 2 steps, 1 precedente al nostro e il nostro, è proprio le info relative a quest'ultimo che alimentano il file excel oggi e il db in futuro.
    Poi se l'ufficio 1 ha un'altro database a noi non importa, dobbiamo registrare e monitorare il nostro operato.
    2)L'operatore Rossi, vede la pratica sull'applicativo quando la pratica supera lo step 1, allora diventa lavorabile e quindi come detto sopra va registrata nel file excel(leggi db)
    3)1 pratica viene assegnata ad un solo operatore che al termine della valutazione in merito alla pratica concluderà lo step 2 e tutto l'iter di accettazione (la pratica di assegnata a Rossi viene data a Bianchi solo se Rossi nel corso della giornata ha impedimenti per cui non può adempiere a quanto assegnatogli, altrimenti resta in capo sempre a lui finchè non esprime un giudizio(esito).
    4)SIamo 20, chi assegna le pratiche al mattino è uno dei 20 operatori, però non può passare la giornata a registrare le pratiche lavorate dagli altri (20*2/3 al gg) quindi ognuno dovrà avere la possibilità di accedere a file access, aprire una maschera e dire ok per me ci sono n pratiche oggi(2 nuove e 1 di ieri che non ho finito). E' chiaro che ci deve essere anche la possibilità che si veda quanto lavorato tipo storico ma può essere una maschera generica dove magari si fa una query per nome e si ricavano le info (aiutami se dico eresie)
    5) ESEMPIO: Mario vuole un prestito e va in agenzia , qui il collega di agenzia lo profila e lo manda in autorizzazione, perchè non sappamo ancora sapere se ha le caratteristiche adatte e quinid prima ricevere soldi va valutato. Il collega di agenzia quindi fa la sua parte e la carica nell'applicativo (cruscotto).
    La pratica cosi arriva in valutazione e quindi diventa visibile ad Ufficio 1, qui verrà appunto valutata e se conforme mandata avanti (ciò comporta l'inseirmento di nota 1 nell'applicativo cruscotto (autorizzo a proseguire o respingo (da parte di Ufficio 1)).
    Fatto ciò diventa finalmente visbile a noi, dove noi lavoreremo un analisi sul profilo del cliente e decideremo se approvare il prestito o meno inserendo alla fine la nota 2 (accettato o rifiutato). Tutto ciò però va tracciato anche all'interno del nostro ufficio, per tenere conto della produttività operatori, tipi di prestiti che ci arrivano, tempi di lavorazione e quindi si svolge quanto elencato in precedenza, cioè da questo applicativo cruscotto uno dei 20 colleghi che che smista /assegna le pratiche ad ognuno (in base a quante ne abbiamo già in carico non finite (quindi senza data fine lavorazione , esito, note)) fa copia e incolla su excel popolando delle colonne (con data flusso, data cruscotto ecc), e qui ciascuno registra le info necessarie per quanto assegnatogli.
    6)L'assegnatore è solo un collega che ha il compito di assegnare e assegnarsi le pratiche giornaliere.
  • Re: Creazione database access lavorazioni ufficio

    OsvaldoLaviosa ha scritto:


    Quest'ultimo post raggruppa troppe domande per essere risolte in un unico thread. Va bene che hai voluto dare più spiegazioni, in quanto te le abbiamo richieste, ma per ora devi fermarti alla fase di PROGETTAZIONE tabelle.
    Che dire: si può semplificare la tabella Pratiche ai soli campi essenziali:
    IDPratica
    NomePratica
    IDOperatore

    poi ci può stare una tabella StoriciPratiche o DettagliPratiche con i campi:
    IDSP o IDDP (numerazione automatica, PK)
    Data
    TipoPassaggio
    IDPratica (FK)

    e magari una tabella
    TipiPassaggi
    TipoPassaggio (PK)

    Relazioni:
    Pratiche.IDPratica uno-a-molti DettagliPratiche.IDPratica
    TipiPassaggi.TipoPassaggio uno-a-molti DettagliPratiche.TipoPassaggio

    Tutto questo presupponendo che una Pratica venga SEGUITA sempre dallo stesso Operatore...

    Spero che ora tu cominci a cogliere il senso dei campi chiave e delle relazioni che ti appaiono arabo dagli esempi dei manuali. Devi scrostarti/abolire ogni logica di Excel e pensare attraverso PIU' tabelle RELAZIONATE.
    Vorrei ben capire queste info che mi stai spiegando, per tipi passaggi che intendi? sono sicuro che se riuscite a farmi uscire dalla logica "EXCEL" (lo uso tutti i santi giorni), riesco a capire meglio tutto
    Grazie sempre
  • Re: Creazione database access lavorazioni ufficio

    Ildono ha scritto:


    per tipi passaggi che intendi?
    A me i campi DataFlusso, DataCruscotto, DataPresaIncarico, DataFineLavorazionePratica, DataScadenzaPratica hanno depistato un "certo" mio ragionamento. Io pensavo che erano questi gli steps di cui si parlava. Mi pare di capire che gli steps sono soltanto 2 e quindi ritornerei sui passi della "non necessità" di uno storico. Quindi non ha più senso parlare di TipoPassaggio.

    Ildono ha scritto:


    5) ESEMPIO: Mario vuole un prestito e va in agenzia , qui il collega di agenzia lo profila e lo manda in autorizzazione, perchè non sappamo ancora sapere se ha le caratteristiche adatte e quinid prima ricevere soldi va valutato. Il collega di agenzia quindi fa la sua parte e la carica nell'applicativo (cruscotto).La pratica cosi arriva in valutazione e quindi diventa visibile ad Ufficio 1, qui verrà appunto valutata e se conforme mandata avanti (ciò comporta l'inseirmento di nota 1 nell'applicativo cruscotto (autorizzo a proseguire o respingo (da parte di Ufficio 1)).Fatto ciò diventa finalmente visbile a noi, dove noi lavoreremo un analisi sul profilo del cliente e decideremo se approvare il prestito o meno inserendo alla fine la nota 2 (accettato o rifiutato). Tutto ciò però va tracciato anche all'interno del nostro ufficio, per tenere conto della produttività operatori, tipi di prestiti che ci arrivano, tempi di lavorazione e quindi si svolge quanto elencato in precedenza, cioè da questo applicativo cruscotto uno dei 20 colleghi che che smista /assegna le pratiche ad ognuno (in base a quante ne abbiamo già in carico non finite (quindi senza data fine lavorazione , esito, note)) fa copia e incolla su excel popolando delle colonne (con data flusso, data cruscotto ecc), e qui ciascuno registra le info necessarie per quanto assegnatogli.
    Immaginiamo 2 esempi:
    Rossi Mario è un Cliente "buono", ha tutte le credenziali a posto e dovrebbe portare a termine in pochi passaggi la Pratica.
    Brambilla Paolo è un Cliente "cattivo", non si sa se sarà accettato subito, potrebbe farcela, ma bisogna esaminare "molte" altre cose.
    Soprattuto in quest'ultimo caso tu hai bisogno di tracciare tutte le fasi di valutazione? Se sì, come intendi farlo? Prevedi un campo Descrizione in cui racconti ogni minima "sensazione" da parte dell'Operatore? Scusa le domande "stupide", ma vorrei capirci meglio su questi piccoli dettagli.
  • Re: Creazione database access lavorazioni ufficio

    Non sono assolutamente domande stupide,capisco bene che non é facile capire meccanismi mai sentiti.
    Allora premesso che sia un cliente buono che uno cattivo passano per il primo ufficio e poi arrivano al mio, la valutazione effettuata sarà sempre accurata e prevederà tutti i controlli che poi si formalizzato con nota 2 dell'applicativo (cruscotto) e che vengono registrati nel nostro file (leggi db) con i campi esito(approvato-rofiutsto) e note(descrizione peculiarità riscontrate) il perché il cliente viene analizzato lo sappiamo a priori quando dell'applicativo ereditiamo(oggi copia e incolla su excel) alcune info (elencate prima)tra cui tipo prestito ( si sostanziano in 3 colonne ,ognuna é un tipo di prestito con risposta si/no, e una esclude l'altra).
    Per ora ho costruito, sulla base dell'operativita immaginata e descritta, una tabella pratiche totale con tutte i campi elencati in precedenza, e alcune tabelle che fanno da pk per alcuni campi della tabella pratiche totale: una tabella esito (id e esito), una operatore (id e cognome) e una tabella mercato (id e mercato(sarebbe il segmento di clientela)).
    Le ho relazionato e nella tabella pratiche totale, per i campi relazionato ho trasformato le celle in caselle combinate così fa avere il menu a tendina.
    Mentre per i campi si/no ho messo questa tipologia di campo, aggiungendo una colonna con lo.stesso.campo si/no per le.pratiche assegnate così da aiutare l'assegnatore con una maschera che prende in automatico le pratiche senza baffo "assegnate".
    Grazie sempre
  • Re: Creazione database access lavorazioni ufficio

    Ildono ha scritto:


    tipo prestito (si sostanziano in 3 colonne ,ognuna é un tipo di prestito con risposta si/no, e una esclude l'altra).
    Se fai 3 campi di tipo Sì/No qualche utente potrebbe commettere l'errore di compilarne più di una, vanificando l'esclusività di cui parli. In questo caso devi usare UN SOLO campo con casella combinata "tri-valore". L'utente ne sceglie uno e il gioco è fatto.
    Per tutto il resto del testo, ancora non ti afferro in pieno. Scrivi i campi tutti attaccati e non si capisce a quale tabella appartengono. Mi pare tuttavia che tu stia cominciando a comprendere l'importanza/potenza dei campi chiave e delle relazioni su più tabelle.
  • Re: Creazione database access lavorazioni ufficio

    I tre campi si/no (che su excel hanno elenco si e no) vengono ereditati dall'applicativo banca, pr esempio se tu vieni per il "prestito di tipo A", avremo SI nella cella "prestito A" e "NO" nelle colonne "prestito B" e "prestito C", siccome è un dato copiato e incollato dall'applicativo (cruscotto) su excel oggi, usare il campo SI/NO al posto di una tabella da relazionare domani su access può dare problemi in fase di utilizzo di query di accodamento?
    Cerco di schematizzare le tabelle create
    Tabella pratiche totali
    - id pratica (PK)
    - data flusso [si eredita dall'applicativo]
    - data cruscotto [si eredita dall'applicativo]
    - id cliente (numerico) [si eredita dall'applicativo]
    - nome cliente (t lungo) [si eredita dall'applicativo]
    - agenzia di riferimento (t breve) [si eredita dall'applicativo]
    - fascia di rischio (t breve) [si eredita dall'applicativo]
    - prestito A (si/no) [si eredita dall'applicativo]
    - prestito B (si/no) [si eredita dall'applicativo]
    - Prestito C (si/no) [si eredita dall'applicativo]
    - data scadenza (sarebbe data cruscotto + 20gg) [si eredita dall'applicativo]
    - data presa in carico [lo scrive l'assegnatore]
    - data fine lavorazione [lo scrive l'operatore ]
    - tipologia valutazione (FK) [lo seleziona da tendina l'operatore]
    - esito (FK) [lo seleziona da tendina l'operatore]
    - note (t lungo) [lo scrive l'operatore]
    - mercato (FK) [lo seleziona da tendina l'operatore]
    - operatore (FK) [lo seleziona da tendina l'assegnatore]
    - assegnata (si/no) [lo scrive l'assegnatore, è un nuovo campo da inserire per access]

    Tabella operatori
    - id operatori (PK)
    - cognomi operatori

    Tabella Mercato

    -id mercato (PK)
    - Mercato

    Tabella esito
    - id esito (PK)
    - esito

    Tabella Tipo valutazione
    - id valutazione (PK)
    - tipo valutazione
Devi accedere o registrarti per scrivere nel forum
30 risposte