Access popolare una tabella con automatismi

Question

Buongiorno e buona domenica. Oggi, per la vostra felicità, si parla di rateazione tasse.......

Ogni anno vengono stabilite le date di scadenza per il pagamento delle imposte; queste date variano in base a 3 variabili:

• tipo cliente: privato (rate scadenti fine mese) e non privato (rate scadenti metà mese)
• posticipo pagamento (Si/No)
• proroga pagamento (Si/No)

da queste ultime due variabili dipende la data di inizio pagamento.

Le combinazioni che scaturiscono danno luogo a 8 diversi tipi di rateazioni, con diverse date di inizio; esempio 1: cliente privato postico NO proroga NO: numero massimo di 7 rate 16/06 - 30/06 - 31/07 - 31/08 - 30/09 - 31/10 e 30/11; esempio 2: cliente non privato posticipo SI proroga SI: numero massimo di 4 rate 22/08 - 16/09 - 16/10 e 16/11, e così via.

In pratica all'inizio dell'anno vorrei inserire le date di decorrenza di pagamento nella tabella "DateInizioRate" e riuscire ad accodare nella tabella "Rate" tutte le 45 combinazioni possibili; ho provato in tutti i modi scervellandomi inutilmente; la difficoltà sta nel popolare il campo "RataNumero" e non solo.

Allego una piccola demo con qualche esempio nella tabella "Rate" (ecco il link):

https://1drv.ms/u/s!AoS1f\_man2ULhqZei6116j6SLP6p4A

Grazie

Ciao Andrea

Answer 1

ciao Andrea,

[...]

In questo modo posso visualizzare per ciascun cliente la situazione dei pagamenti e, accodando i dati dei vari clienti in una tabella, ottenere un report con l'elenco dei clienti con pagamenti in scadenza ad una determinata data (che è il vero obiettivo per lo studio).

[...]

no, non proprio accodare, nel senso che per come l'ho pensata io, il calcolo può essere effettuato al volo quindi non serve memorizzare totali.

Chiaro che in caso di esigenza di archiviazione di dati storici nulla ti vieta ti memorizzarli in una tabella.

[...]

Sarei curioso di verificare come hai strutturato la tua demo; potresti per cortesia postarla (ovviamente se non ti torna male) ?

[...]

si nessun problema : demo.

non ho posto alcun controllo nel caso in cui si scelga l'opzione di pagamento rateale e le rate non siamo impostate, in tal caso il calcolo è fuoriviante...

in pratica scegli l'opzione di pagamento clicchi su calcola e vedi i risultati.

come detto nel caso di pagamento rateale imposta il numero delle rate.

Ho impostato un rudimentale report che mostra gli stessi dati che hai nella maschera.

Ho inserito anche una query in join per il rankig, se vuoi divertirti ad implementarla un po'....il join garantisce performance superiori rispetto alle subQueries.

se la apri in struttura griglia fanne prima una copia, l'ottimizzatore la modifica...

[...]

Grazie ancora

Andrea

prego e buon sabato a te.

Ciao, Sandro.

Answer 2

Grazie come al solito. E' veramente difficile per i non addetti ai lavori capire...................e per me (addetto ai lavori) capire le scelte del Ministero !!!!!

E' proprio la necessità di elasticità che mi ha portato a modificare il database; ogni anno il ministero cambia infatti le date e il database, per come era strutturato, andava in crisi.

Provo a chiarire i tuoi dubbi:

La scadenza di default per tutti i contribuenti è il 16/06 di ogni anno. Ogni contribuente può decidere di posticipare detta scadenza al 16/07, con un aggravio di interessi: questa è una facoltà e riguarda chiunque.

Per chi decide di pagare ratealmente (una facoltà, anche nella determinazione del numero delle rate) esistono però scadenze diverse per le rate successive alla prima, a seconda che si tratti di privati o soggetti con partita Iva: per i primi le scadenze successive cadono a fine mese per i secondi il 16 del mese. L'importo della singola rata è pari al totale diviso il numero delle rate (con interessi di rateazione, ma ho un'apposita Query per il calcolo).

Esistono poi alcune categorie di contribuenti per i quali tutti gli anni viene stabilita una proroga dal Ministero; la proroga sposta in avanti la data iniziale di pagamento: quella del 16/06 diventa 06/07, quella del 16/07 diventa 22/08 (però lo scorso anno non era il 6 ma il 07/07 e non il 22 ma il 20/08). Quindi sia la proroga che il posticipo vengono inseriti manualmente dagli operatori dello studio in una maschera, in modo da identificare le rate; i dati inseriti nella maschera sono:

• l'ID cliente (di conseguenza sappiamo se è privato o no);

- l'importo totale da pagare e il numero delle rate;

• proroga ministero (casella di controllo) se flaggata sposta la data di I pagamento del 16/06 al 06/07;
• posticipo pagamento (casella di controllo) se flaggata sposta la I data di pagamento dal 16/06 al 16/07, ma se tutte e due le caselle di controllo sono flaggate la prima data di pagamento sarà 22/08.

Una volta inserite le informazioni, una Query calcola l'importo delle singole rate e le date di scadenza (nella vecchia versione con le date fisse); ma il problema dei giorni festivi (oggetto di un'altra domanda brillantemente risolta in questa community) e la mutabilità delle scelte del Ministero mi hanno costretto ad affrontare il problema per rendere il DB più elastico.

Quindi nella Query che calcola le rate vorrei inserire una tabella con: Id_tipo cliente (privato e non), ID_anno e tutte le date di scadenza per le rateazioni, in modo che per ogni cliente, sulla base delle scelte inserite nella maschera, vengano agganciate le date giuste. Per evitare tuttavia di inserire tutte le date a mano (quest'anno 45 combinazioni di rateazione), vorrei che la tabella in questione fosse creata automaticamente una volta inserite le 4 date originarie (quest'anno 16/06, 06/07, 18/07 e 22/08).

Spero di non avervi tediato troppo e che il tutto sia sufficientemente chiaro. Grazie per la pazienza.

Andrea

Answer 3

ciao Andrea,

quindi non ti serve un modo per elaborare tutte le combinazioni possibile, ma in base allo status del cliente, al fatto che decida di prorogare piuttosto che no e in base anche a questo :

[...]

ma se rientra in determinate categorie di contribuenti può usufruire della proroga (variabile 3)

[...]

che è un'ulteriore discriminante, la data di pagamento può essere a sua volta diversa da quanto indicato nelle possibile combinazioni identificate per default dalla query mostrata prima.

sulla base di che cosa la categoria specifica ti consente di spostare la data dal 16.06 al 06.07..la proroga è fissa?

Nel caso il cliente X ricada in questa possibilità al cliente Y che appartiene alla stessa categoria verrà applicata la stessa dilazione ? oppure il calcolo è ancora diverso...? e anche le scadenze?

Le categorie quali sono...? alle categorie viene applicato sempre la stessa dilazione oppure varia da caso a caso?

[...]

In sostanza la scelta iniziale (proroga SI/NO + posticipo SI/NO) determinata la data di pagamento della prima rata (4 combinazioni);

[...]

non lo metto in dubbio ma da come ci dici mi sembra che anche la categoria abbia la sua influenza.

poi....il calcolo delle rate è esattamente l'importo totale diviso per il numero delle rate o anch'esso può variare?

Senza capire molto ( per mia totale ignoranza nella materia non certamente per la tua modalità espositiva) mi sentirei di dirti di provare a stabilire tutte le varie possibilità, valutare le tabelle di riferimento di conseguenza.

in fase popolamento dati queste tabelle saranno l'origine dati di controlli non associati e sarà una routine VBA che ti permetterà di calcolare la data/ date in base alle varie regole.

Essedo un aspetto molto variabile non credo sia il caso di stabilire importi e scadenze sulla base della query suggerita in precedenza vista l'alta probabilità che le variabili in gioco siano molteplici e magari....il prossimo anno ulteriormente diverse...

Cercare una soluzione il più possibile flessibile credo sia la cosa migliore in modo da apportare per gli anni prossimi cambiamenti minimali e non completamente strutturali.

Facci sapere, la cosa in interessa come sempre tantissimo.

Ciao, Sandro.

Answer 4

Grazie per la risposta Sandro. Siccome siamo in Italia e le cose non possono per default essere semplici, il risultato della Query non è esattamente quello che mi serve, anche se il tuo suggerimento è utile. Cerco di spiegare meglio.

Supponiamo che il cliente abbia da pagare imposte per € 1.000, che sia privato (variabile 1) e che decida di pagare in 4 rate; a questo punto può decidere di pagare la prima rata senza posticipo (16/06) o con posticipo (16/07) (variabile 2); ma se rientra in determinate categorie di contribuenti può usufruire della proroga (variabile 3) che sposta la data di pagamento della prima rata rispettivamente al 06/07 (quella del 16/06) o al 22/08 (quella del 16/07).

In sostanza la scelta iniziale (proroga SI/NO + posticipo SI/NO) determinata la data di pagamento della prima rata (4 combinazioni); siccome ogni anno il ministero stabilisce date di inizio pagamento diverse, una volta inserite le date iniziali avrei la necessità di ottenere una tabella con le rate successive alla prima suddivise tra cliente privato e cliente non privato. In questo modo ottengo per ciascun cliente l'importo delle singole rate per ogni scadenza.

Spero che sia chiaro.

Grazie Andrea

Answer 5

ciao Andrea,

dimmi se sbaglio.

2 tipi clienti * 11 scadenze * 2 tipi pagamento = 44

modificando leggermente il tuo DB in questo modo :

T_proroga:

T_rate:

T_tipocliente (invariata, meglio se non lasci spazi nei nomi di campi, tabelle, controlli....vedi tipo cliente) :

poni le tra tabelle in cross join :

SELECT t1.proroga

            , t2.dataRata

            , t3.[Tipo cliente]

FROM

            t_proroga as T1, t_rata as t2, t_TipoCliente as t3

ORDER

            BY t2.dataRata, t3.[Tipo cliente];

ottieni ( spaccato del risultato):

da qui poi crei una tabella, accodi dati...ect...

ciao, Sandro.