Esegui ricerca con variabile Risolto!

[superbuc]

Ho inserito una variabile calcolata che mi permette di andare in uno specifico formato, ma mi sono arenato subito dopo.
Nello script il passo successivo è "Esegui la ricerca" ma per dare un valore devo per forza scegliere una delle tabelle proposte.
Invece io dovrei poter scegliere una tabella in base alla mia variabile.

Ad esempio se il codice listino è 001, devo eseguire la ricerca sulla tabella MAGAZZINO001, se è 002 ricerca su MAGAZZINO002 e così via...
Mi sa che devo per forza trovare una alternativa gestendo tutte le possibilità nello stesso magazzino, no ?

[fabio.beri]

Scusami, fattelo dire: Hai sbagliato la struttura dei dati.
Una struttura del genere che fa si che in funzione di un codice si debba fare ricerche in tabelle diverse è SBAGLIATA.

Tecnicamente, la risposta alla tua domanda è usare un VAI AL FORMATO (PER NOME FORMATO) dove per nome formato userai il calcolo: "MAGAZZINO" & $codice_listino

e questo ti consente di spostarti e fare una ricerca dinamica, ma poi tanto dinamica non può essere perché se domani sei arrivato al listino 100 (visto che prevedi tre numeri) vorrà dire che hai creato 100 tabelle ? NON VA.

Rivedi la struttura e pensa alla tua soluzione in modo diverso.

[superbuc]

Non ti ho dato altri dati, forse per questo mi dici che la struttura per te è sbagliata.
Ma sono aperto a ogni variazione, ovviamente.

Il listino GENERALE è uno, e ha 100.000 record, con i dati di ogni articolo, fra cui ovviamente il codice articolo.
Nel vecchio gestionale c'erano una dozzina di listini con altrettanti record in ognuno, ma solo alcune (poche) variazioni di prezzo.

Nel mio sistema io tengo il listino generale da 100.000 e con un IF dico allo script di andare all'altro listino, quello corrispondente a quel determinato cliente, SE appunto l'intervento è relazionato a quel cliente.
I miei listini, o sottolistini se vogliamo, contengono pochissimi dati, e pochissimi campi.
Ci sono in pratica solo il codice articolo e il prezzo, che è diverso.
Nel listino più grande ho 2000 articoli, negli altri ne ho da 50 a un minimo di 2 (in questo caso variano solo due prezzi).

Avrei potuto gestire la stessa cosa mettendo nel listino generale altri campi, con i vari listini, no ?
Ma ho una necessità diversa, che secondo me rende più adatto l'approccio che ho avuto.
Io devo poter:

1) stampare i vari listini in una frazione di secondo (il capo chiede...)
2) BLOCCARE i listini quando consegnati al cliente, non sono più modificabili nel prezzo
3) Al contrario poter aggiornare il listino generale con file esterni dei fornitori, che mandano aggiornamenti sul prezzo, sconti, ecc.

I sottolistini hanno, è vero, tre cifre, ma non saranno mai più di una decina, una dozzina al massimo. Le tre cifre hanno un significato "storico" che ho voluto mantenere per la tranquillità degli utilizzatori del vecchio sistema.

Pensi ancora che sia sbagliato, questo sistema?
Come avrei potuto gestirlo, considerando sempre i 3 punti sopra?

Grazie comunque, avevo trovato la soluzione come me l'hai suggerita tu, dopo una ricerca sul manuale.

Adesso lo script legge il codice cliente di quell'intervento, va nell'anagrafica cliente a leggere che listino usa, va al listino con quella variabile MAGAZZINO & CODICE LISTINO, legge il prezzo e lo inserisce nell'intervento.
Se il prezzo non esiste, perchè l'articolo non esiste in quel listino (ovviamente accade, visto che nei listini ci sono molti meno articoli di quello generale), lo script va al listino generale e prende il prezzo generale, avvisando comunque l'utente di quello che sta facendo.

Ho fatto così per non avere inutilmente duplicati i listini, che sarebbero stati uguali nel 99,9% dei record.

[fabio.beri]

Dunque, se hai fatto più di una tabella listino, hai sicuramente sbagliato.

Faccio un esempio semplificando la questione, riportandoti anche la struttura del nostro OmniaGest

I listini sono inevitabilmente 2, uno in vendita e uno in acquisto, quindi ho due tabelle solamente per questo motivo: ogni fornitore ha un listino di acquisto, mentre in vendita potrei fare scelte diverse (uno per cliente, uno generale, uno per categoria di clientela...).

Detto ciò parliamo solamente della parte vendita: il listino deve essere uno così, SEMPLIFICATAMENTE composto:

codice LISTINO, codice articolo, nome articolo (se vuoi), prezzo... e altri se vorrai (percentuali sconto, importo scontato...)

Ma vorrei focalizzare la tua attenzione su codice listino

Se hai una gestione di listini per cliente, il codice listino deve essere la chiave di corrispondenza tra il listino e l'anagrafica del cliente, quindi quando sto facendo una vendita ad un cliente, lui avrà un codice listino di corrispondenza e quindi porterai l'operatore a scegliere un prodotto facendo una semplice ricerca sul codice listino che il cliente ti ha fornito.

C'è un'altra situazione. Quella in cui il cliente ha PIU' DI 1 listino, allora è diverso. La tabella listino avrà oltre i campi già citati anche il CODICE CLIENTE perché la corrispondenza sarà 1 cliente a TANTI listini, quindi la tua relazione sarà diversa e in tal caso farai in questo modo

1. Prendo il codice cliente
2. Chiedo al cliente quale listino (di quel cliente)
3. Ricerco per codice listino e codice cliente
4. Mostro i prezzi all'operatore per scegliere l'articolo (con il giusto prezzo) che vuole vendere/selezionare.

Relativamente a questi tre punti

1) stampare i vari listini in una frazione di secondo (il capo chiede...)
2) BLOCCARE i listini quando consegnati al cliente, non sono più modificabili nel prezzo
3) Al contrario poter aggiornare il listino generale con file esterni dei fornitori, che mandano aggiornamenti sul prezzo, sconti, ecc.

Qual'è il problema?

FileMaker 13 o 14 o 15 consentono di gestire grande mole di dati e il 15 è ancora più performante. Che ci vuole a fare una stampa? anche se fossero 1.000.000 di record con 10 campi, quanto vuoi che ci metta a ricercarli ? Diverso è se lavori con un FileMaker 6 (piuttosto, volete mettere la versione FileMaker che utilizzate nella firma del profilo fmpro.it?).

Qual'è il problema nel bloccare il listino che sia una o siano più tabelle? Fallo con i privilegi. E' più performante

Anche OmniaGest gestisce il caricamento dei listini dei fornitori consentendo il caricamento di qualsiasi impostazione di flusso (colonna 1/2/3/4 che sia codice, piuttosto che nome prodotto, piuttosto che prezzo...), ma che c'entra con il listino di vendita? E' un tema diverso

Questo è la struttura che ho trovato in OmniaGest quando sono arrivato a lavorare in Omnia Studio e fino ad oggi non si sono riscontrate criticità.Ti invito a ragionarci sopra

[superbuc]

Tutto chiaro, e fino a qui siamo esattamente nello stesso caso che ho costruito.
Ho il codice listino per ogni cliente.

Una volta che lo script ha trovato il codice listino del cliente X, e il codice listino è 001, il sistema dove va a leggere il prezzo di quell'articolo con quel listino ?

Tu e io compriamo lo stesso chilo di arance, con il cod. ARANCE01
Tu hai un listino dove le paghi 10 euro al chilo (listino1), e io le pago 7,50 euro al chilo (listino2).

Il sistema va e trova ARANCE01, poi vede che tu hai il listino 1 e io il listino 2.
Quindi come faccio a non avere più listini ? Il sistema prende il prezzo del listino 1 per darlo alla tua fattura, mettiamo, e il prezzo del listino 2 per darlo alla mia.

Tu metteresti i prezzi nella stessa anagrafica (il listino 1 diciamo) dove io trovo ARANCE01 poi il campo listino 1 e il campo listino 2 ecc. ecc ?

[superbuc]

E comunque l'importazione e gli aggiornamenti dei listini di cui parlavi c'entrano eccome.
Sempre per le arance che io e te compriamo tu a 10 e io a 7,5 euro/kg, il rivenditore, la mia ditta, le compra a 4 euro oggi, e domani magari a 4,5 perchè il fornitore di arance ha mandato un listino aggiornato, con una maggiorazione.
Il ricarico rimane di TOT percentuale, ed ecco che il listino del prezzo di vendita aumenta in automatico.

Di conseguenza il prezzo tuo potrebbe aumentare, perchè è un prezzo di un listino che si può aggiornare (il listino1), mentre il mio prezzo non cambierà per i prossimi 10 anni perchè ho un accordo con un mio listino sempre a 7,50 /kg (listino2).

[fabio.beri]

Io NON ti ho scritto che non devi avere più listini, anzi ti ho scritto che sicuramente potrai avere più listini.

Però ti ho scritto che i listini devono stare TUTTI dentro la stessa tabella e agganciati ad un campo CODICE LISTINO

Quindi io avrò, per esempio

Codice: Seleziona tutto

COD. ART.		NOME ARTICOLO			CODICE LISTINO			PREZZO DI VENDITA
ARANCE01		ARANCE SICILIA					001					1,45
ARANCE01		ARANCE SICILIA					002					1,82
ARANCE02		ARANCE MAROCCO					001					0,85
ARANCE02		ARANCE MAROCCO					002					0,92

Quindi il prezzo viene dato da FileMaker in funzione dei due elementi che sono COD. ART. e CODICE LISTINO

Chiaro fino a qui?

Per risolvere il problema delle variazioni del prezzo di vendita che si aggancia (INEVITABILMENTE) al prezzo di acquisto, la strada è questa:

Codice: Seleziona tutto

COD. ART.		NOME ARTICOLO			CODICE LISTINO			PREZZO DI VENDITA		MARGINE		PREZZO DI COSTO
ARANCE01		ARANCE SICILIA					001					1,45						10%				1,00
ARANCE01		ARANCE SICILIA					002					1,82						15%				1,00
ARANCE02		ARANCE MAROCCO					001					0,85						10%				0,60
ARANCE02		ARANCE MAROCCO					002					0,92						8%				 0,60

(i valori sono indicativi. Non mi sono messo a fare i calcoli, ma sono frutto di un esempio)

In questo modo il prezzo di vendita è calcolato AUTOMATICAMENTE (con script o con campo calcolato, è uguale) in funzione del prezzo di costo che variando, fa si che il software applichi il margine desiderato per rimodulare tutti i prezzi di vendita dei listini.

Che mi dici?

[superbuc]

Ok, ora è chiaro, scusa se ti ho fatto fare lo schema !
Non ho problemi a metterli insieme, d'accordo, ma qual è il motivo, alla fine ?

Per non far fare una ricerca in un formato diverso, in più, allo script ?
Per velocità?

Devo rivedere a questo punto l'IF quando non c'è l'articolo nel listino assegnato, visto che in un'evenienza del genere lui andrebbe a prendere il prezzo sul listino di base, 001.

Bello l'esempio delle arance, siamo quasi in stagione eh ?

[fabio.beri]

La motivazione di una struttura del genere è ricondotta solo al fatto che, dovendo creare più listini, non è logico, ma anche tecnicamente valido, usare una tabella per ogni listino.

Non è solo per posizionarsi sul formato giusto (arghhhhhh), ma anche per una ragione di sviluppo (ogni modifica fatta su una tabella va replicata sulle altre) e anche lo sviluppo di script aumenta in funziona delle tabelle che introduci.

Insomma... UNA VERA FOLLIA.

In OmniaGest abbiamo clienti che caricano e usano contemporaneamente più listini nello stesso anno per ogni cliente. E' facile arrivare anche a 10.000 listini di vendita e per listini intendo solo il contenitore di prezzi, poi in un'altra tabella ci devi mettere i records dei prezzi.

Secondo te, potevamo fare 10.000 tabelle ?

[fabio.beri]

Comunque, si, mi hai fatto pure farti il disegnino...

In che città stai? ce l'ho la colazione offerta ?