Newsgroup: it.comp.appl.access
Titolo: gestione contatore preventivi in rete con più operatori

buongiorno a tutti, spiego il mio problema
il contatore vale 0
 
un operatore crea un preventivo, il contatore viene incrementato a 1
poco dopo un altro operatore crea un altro preventivo  il contatore viene incrementato a 2
successivamente il primo operatore annulla il suo preventivo 1 e quindi dovrei decrementare il contatore a 0 ma nel frattempo è stato creato il preventivo 2
 
quindi come gestire correttamente il contatore?
forse decrementandolo soltanto se il valore di contatore coincide con il numero di preventivo che sto annullando? e se non fosse cosi?
 
grazie.


è sbagliato usare il contatore come numero del preventivo.
il numero al preventivo dovrebbe essere un campo a se, il cui valore 
viene calcolato solo al salvataggio del preventivo.
 
esempio uso come numerazione preventivi il seguente formato
 
xxxx/aa/rev
 
dove
xxxx è un numero progressivo
aa=anno
rev=revisione del preventivo
 
quindi qualcosa tipo
1/22/1
2/22/1
1/22/2
3/22/1
 
etc etc
 
BFS
 
 
 
 
 
 


mi sono spiegato male, ho una tabella personalizzata di nome contatore con all'interno un campo di nome contatore di tipo intero
quando creo un preventivo incremento quel contatore e creo il nuovo preventivo
 
cliccco nuovo preventivo --> contatore=contatore+1 
se era 0 diventa 1
 
se poco dopo un altro operatore clicca nuovo preventivo --> contatore=contatore+1 diventa 2
 
il primo operatore però decide di annullare il preventivo quindi in teoria dovrei decrementarlo da 1 a 0 ma è già 2 a causa del secondo preventivo quindi se lo decremento diventa 1
 
la soluzione è quella di assegnare il numero al preventivo solo alla fine quando cliccano su salva preventivo? ho capito bene? ma se fosse cosi come posso stampare il preventivo se non ha ancora un numero fino a che non lo salvo?
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 


almeno io, il numero preventivo/bolla/fattura lo assegno al momento in 
cui salvo il documento. e solo a numero assegnato si attivano i pulsanti 
per la stampa, mail etc.
nulla vieta di poterlo stampare cmq prima del salvataggio visto che la 
chiave primaria gia esiste...lo stamperai ovviamente con numero 0
 
Questo mi risparmia fastidi del tipo:
utente A inizia a fare un preventivo che prende il numero 1
utente B inizia a fare un altro preventivo che prende il numero 2
utente A si rompe del preventivo  e lo elimina
Utente B si trova con un preventivo 2 e nessun preventivo 1
 
ad ogni modo, in caso di cancellazione di preventivi vecchi e quindi con 
la creazione di buchi nella numerazione non lo vedo un problema 
personalmente
 
ora che neppure le fatture richiedono numeri progressivi il problema non 
me lo pongo proprio.
 
per alcuni clienti particolarmente legati alla progressività del numero 
ho cmq previsto la funzione "cambia numero"
quindi se ho i preventivi 1/22 2/22 e 3/22
per qualche motivo viene cancellato il 2/22 creando il buco
 
quando si fa un nuovo preventivo, in fase di salvataggio in automatico 
prende 4/22 ma con questo pulsante posso far decidere un nuovo numero 
all'utente...che può scegliere 2/22 (per coprire il buco) Ovviamente ho 
messo un controllo per evitare che cambi il numero con uno gia esistente
 
ovviamente al progressivo numerico non corrisponderà un progressivo 
delle date
 
ma ribadisco trovo personalmente inutile la progressione numerica nei 
documenti.
 
ho alcuni clienti che chiedono proprio di non mostrare il numero 
progressivo perchè per loro se il cliente vede un numero basso di 
preventivi/ordini verso fine anno significa che lavorano poco.
in questi casi la numerazione che assegno è PR220831 (PR+data in formato 
americano)
 
BFS
 
 
 
 
 
 

> 
 
esatto, lo faccio in una procedura che genera calcoli di prezzi
 
in pratica, lavorando su una tabella locale temporanea, suggerisco il 
numero da usare, il primo libero dopo il più alto che trovo nella tabella 
dei preventivi salvati
 
l'utente in genere lo accetta perché non si fanno frtur zragnyv sulla 
consecutività, ma può anche cambiarlo al volo: il programma ricontrolla che 
non sia già in uso (vedi sotto)



ma perché? nel senso... se il preventivo viene annullato, in una campo ci scrivi "annullato" (o inserisci un campo flag) e vai avanti.
se vuoi il numero di preventivi non annullati fai una query.
il preventivo così rimane in memoria per successive analisi.

 
 
l'OP dovrebbe lavorare un po' con SAP, per apprezzare a pieno il comando
"Cancel" ("Interrompi" in italiano") e le sue conseguenze sui contatori
;) 

Il 30/08/2022 21:35, mario rossi ha scritto:

La stessa identica cosa succede se oggi si fanno 10 preventivi
Domani qualcuno CANCELLA il preventivo n.5 , resta il buco
Quindi, la possibile non consecutivita' numerazione, e' inevitabile
 
 
 
 


non ho capito cosa intendi per "frtur zragnyv"


Ho optato per questa scelta, ho anche previsto di recuperare un preventivo annullato se volessero non lasciare buchi
 
grazie.

 
 
questo è il meno, la cosa importante è che tu ti sia chiarito che il 
concetto di consecutività/sequenzialità/ecceteretà non è più così 
fondamentale nemmeno per il fisco italiano
 
p.s.
cerca ROT13