Newsgroup: it.comp.appl.access
Titolo: Non esattamente un Saldo Progressivo...

Salve a tutti e come sempre grazie per l'assistenza. 
Scusate se torno su un tema già trattato e (per me) non risolto. 
Ho letto in alcuni post la soluzione del Saldo Progressivo risolto con 
l'espressione DSum("[Entrate]-[Uscite]";"nomeTabella"";"Id<=" & [Id])
Molto intrigante, ma non è esattamente ciò che serve a me.  
A me servirebbe la tipica situazione di ogni conto corrente, dove da una parte c'è una Somma Debito e dall'altra ci sono acconti  
 
Descrizione   Importo    Versati  DataVersamento  SOMMASaldo 
AAA           2000          500    01/05/2018      3500  (cioè 4000-500)
BBB           1000          200    10/05/2018      3300  (4000-700) 
CCC           1000          100    20/05/2018      3200  (4000-800) 
 
Tali saldi appaiono ovviamente di volta in volta nel campo calcolato della maschera ma a me serve che vengano "registrati" al momento del versamento.  
Sull'Evento DopoAggiornamento di qualsiasi campo non sono mai riuscito a "fotografare" il saldo su un campo.
 
Dove posso trovare la soluzione che fa al mio caso ?


rilievo del tutto personale (sottolineo personale),
che concerne SOLO il meccanismo di calcolo:
 
da come poni la cosa appare che ogni movimento (importo) "successivo" 
debba essere considerato retrospettivamente nel valore dei saldi
e quindi, di fatto, NON sia proprio un meccanismo simile 
al conteggio di uno "scalare di c/C" che indichi come riferimento 
 
In altre parole:
nel caso si tratti di una successione di acquisti e pagamenti 
(QUESTI ULTIMI solo parziali ?)
come fa colui che acquista ad avere la soddisfazione di vedere un saldo ?
DEVE smettere di acquistare ?


Ciao Giorgio, grazie per la risposta.
Effettivamente non tutti i conti correnti danno il saldo retrospettivo, lo faceva il mio C/C: ad ogni data movimento, un saldo ma tra quelli attuali non ne vedo più.
In ogni caso serve talvolta sapere per esempio, al 31/12, qual era la situazione contabile. Oppure sapere mensilmente qual è la situazione, quindi occorre avere una "fotografia" del momento. Infine, avere un campo "fisso"  in tabella o query (e non calcolato sulla maschera) serve in determinate informazioni che si vogliono ottenere attraverso Recordset.
...Insomma ci sono svariati motivi per ottenere il totale... in una riga!
Ho provato decine di routine "DopoAggiornamento" ma access  fa appunto il calcolo DOPO l'aggiornamento e non contemporaneamente. Ho provato a inserire una requery nella routine. Funziona ma il puntatore del record si riposizione ad ogni requery (o recalc) sempre sul primo record , creando non pochi fastidi!.... :-( 

Scusa ma puoi allegare un file per vedere come hai operato fino ad ora, in quanto da quanto esposto è difficile darti un consiglio.

 Scusa ma puoi allegare un file per vedere come hai operato fino ad ora, in quanto da quanto esposto è difficile darti un consiglio.
 
Scusa ma non l'ho mai fatto.
Devo inviare la maschera e la tabella questione?
Come si fa a inviare qui un Db? 

After serious thinking Marco wrote :

Che sistema operativo e quale versione usi?
 
Bruno

Condividi il file su un sito specifico (es.BooleBox, Google drive, ecc...)
quindi scrivi il link.

 quindi scrivi il link.
 
Ecco il link
https://drive.google.com/open?id=1eLPOEKZ-7tShdcGKRIQ8lOf2TdT8QpYO
 


Ciao Bruno.
Access 2007-2010
su diversi Sistemi Operativi: Win 7 e Win 8

Intanto direi che dovrebbe essere 
 
Descrizione   Importo    Versati  DataVersamento  SOMMASaldo
AAA           2000          500    01/05/2018      1500 (2000-500)
BBB           1000          200    10/05/2018      2300 (3000-700)



No,
considera che i valori del Campo Importo siano immessi prima, in un unica data e poi, come se fossero delle rate, vengono effettuati i versamenti.

Il giorno venerdì 25 maggio 2018 21:59:06 UTC+2, 
carl...@gmail.com
 ha scritto:

....
Infatti la Data è riferita al versamento, non c'è una data riferita agli importi.

Io la risolverei inserendo nella maschera SchedaCliente i seguenti eventi:
 
Private Sub Importo_AfterUpdate()
    CalcolaSaldo
End Sub
 
Private Sub Versati_AfterUpdate()
    CalcolaSaldo
End Sub
 
Private Sub CalcolaSaldo()
Dim curTotaleImporto As Currency
Dim curTotaleImportoVersato As Currency
    curTotaleImporto = Nz(DLookup("Sum(Importo)", "SchedaClienteDett", "IdSchedaCliente = " & Me.IDSchedaCliente), 0)
    curTotaleImportoVersato = Nz(DLookup("Sum(Versati)", "SchedaClienteDett", "IdSchedaCliente = " & Me.IDSchedaCliente & " AND Posizione < " & Me.Posizione), 0)
    Me.SaldoVers = curTotaleImporto - curTotaleImportoVersato - Me.Versati
End Sub
 
Ho usato questa riga:
    curTotaleImporto = Nz(DLookup("Sum(Importo)", "SchedaClienteDett", "IdSchedaCliente = " & Me.IDSchedaCliente), 0)
in quanto, dal database postato, è l'unico modo per sapere il quale è il totale delle spese per un certo cliente
 
Se mi permetti però varrei segnalarti alcuni, per me, difetti nel progetto:
•	La mancanza di integrità referenziale fra le tabelle Rubrica e SchedaCliente, SchedaCliente e SchedaClienteDett
•	Mancanza nella struttura delle tabelle di controllo della proprietà:
o	Dimensione campo, dare una dimensione congrua e non sempre 255
o	Richiesto, per imporre l’obbligatorietà dell’immissione del dato se questo e fondamentale per la correttezza della gestione del database
o	Indici, presenza di duplicati degli stessi e mancanza di un indice che eviti la duplicazione dei record
•	Nelle maschere:
o	uso nei controlli dello stesso nome per Origine controllo e Nome elemento
o	blocco tramite la proprietà Bloccato della possibilità di inserire dati direttamente di valori in campi calcolati come nel caso del saldo
 


Ti ringrazio molto. Non sapevo che con DLookUp potesse farsi anche questo. Anche se...ad essere sincero, non ho ancora capito bene come funzionano i criteri finali:
"IdSchedaCliente = " & Me.IDSchedaCliente & " AND Posizione < " & Me.Posizione), 0)
 
Ho provato il codice e funziona, l'unico difetto è nella prima registrazione. Se partendo da Zero provi a scivere:
Importo 2000 e Versati 1000
il Saldo ti da -1000
 
Per quanto riguarda le tue osservazioni/consigli hai ragione. 
Alcuni dei particolari mancano perché ho postato un vecchio progetto di questa maschera, non ancora provvista di alcuni accorgimenti per la "sicurezza". 
(Le Relazioni nel progetto attuale ci sono). 
Altri... non ho capito. Per esempio quando parli di indici: se c'è la chiave primaria la Tab non è indicizzata? 

Il giorno sabato 26 maggio 2018 05:55:05 UTC+2, 
carl...@gmail.com
 ha scritto:

------------------------------------
Inoltre ho notato che se torno a digitare qualche valore PRECEDENTE,
(Per esempio avevo scritto 1000 e correggo con 1100)
il calcolo è errato e il saldo Maschera non corrisponde con quello del Record.

Se ho capito bene, basta modificare il codice nel seguente modo:
 
Private Sub CalcolaSaldo()
Dim rs As DAO.Recordset
Dim lngIdSchedaCliente As Long
Dim lngPosizione As Long
Dim curTotaleImporto As Currency
Dim curTotaleImportoVersato As Currency
    On Error Resume Next
    Me.Recordset.Edit
    Me.Recordset.Update
    lngIdSchedaCliente = Me.IDSchedaCliente
    lngPosizione = Me.Posizione
    Set rs = CurrentDb.OpenRecordset("SELECT * FROM SchedaClienteDett WHERE IdSchedaCliente = " & lngIdSchedaCliente & " ORDER BY Posizione")
    curTotaleImporto = Nz(DLookup("Sum(Importo)", "SchedaClienteDett", "IdSchedaCliente = " & Me.IDSchedaCliente), 0)
    Do While Not rs.EOF
        curTotaleImportoVersato = Nz(DLookup("Sum(Versati)", "SchedaClienteDett", "IdSchedaCliente = " & lngIdSchedaCliente & " AND Posizione <= " & rs!Posizione), 0)
        rs.Edit
        rs!SaldoVers = curTotaleImporto - curTotaleImportoVersato
        rs.Update
        rs.MoveNext
    Loop
    Me.Requery
    Me.Recordset.FindFirst "IdSchedaCliente = " & lngIdSchedaCliente & " AND Posizione = " & lngPosizione
End Sub
 
- Se c'è la chiave primaria la Tab è indicizzata per quanto riguarda quel campo ma ad esempio nella tabella Rubrica non esiste nè un indice univoco per la P.I. nè per il C.F. il che potrebbe causare l'mmissione di record con valori che già sono assegnati ad altri record cosa che non dovrebbe accadere.
 
Comunque torno a dirti che il progetto, a parere mio per quello che si vede dal progetto postato, non è gestito nella maniera dovuta in quanto, per esempio, aggiornare un Versamento sotituendo il valore precedente con quello nuovo non ti permette di avere la visione dello storico dei movimenti, cosa che credo invece sia importante.
Ecc..


Bene... a quanto pare ho un po' di codice da analizzare domani ! 
 
Ho indicizzato (senza duplicati ammessi) i campi P.I e C.F 
 
Per quanto riguarda la tua ultima osservazione:
ti riferisci a ciò che ho scritto nell'ultimo Post?
Cioè "se torno a digitare qualche valore PRECEDENTE"?
 
Certo, così facendo lo storico si perderebbe,
ma io intendevo dire che se per errore, sbadatamente,
l'utente scrive 1000 anziché 1100 e poi va a correggere tale errore, il conto non torna più perché c'era quella sottrazione (-Me.Versati) 
 
Ps. non ho capito quel Me.Recordset
Mai usato. Cos'è , una specie di RecordsetClone?

E' il recordset assegnato come Origine record alla sottomaschera.