Ciao.
Ma vedi, il problema non è se devi immettere la percentuale, il prezzo o altri elementi.
Tutto è fattibile.
Almeno per me, cercavo di allievarti il fatto di dover inserire una marea di dati, sopratutto ripetuti e se si potevano automatizzare alcune operazioni, ti si evitava del lavoro, ma siccome i preventivi vengono creati su logiche che variano di volta in volta, almeno per me, le soluzioni che rimangono sono simili ad un foglio automatizzato di excell.
Per carità, nulla a che vedere con excell, tutto più automatizzato e performante, ed una volta che hai inserito tutti i dati, diventa tutto a portata di un semplice click. (più o meno )
Ora rimane da capire se è meglio creare la struttura come elemento principe basato sugli articoli, oppure se l'elemento principe sono i listini.
Mi spiego.
Le soluzioni che mi vengono in mente più performanti sono:
Hai come elemento principale l'articolo, al quale vai a collegare il nome del listino i prezzi gli sconti e tutto quello che vuoi,
Oppure hai il nome del listino al quale vai ad inserire l'articolo, i prezzi etc etc.
Con la prima soluzione hai una tabella articoli con un collegamento 1 a molti verso una tabella listini.
Con il secondo invece hai una tabella listini con collegamento 1 a molti con gli articoli.
Con la prima soluzione immetti i 350 articoli una volta sola ed i prezzi sono svincolati dal listino(cioè verranno archiviati con l'articolo, il listino di appartenenza sarà semplicemente un'etichetta) e quindi per l'ìimmissione dei listini non farai altro che richiamare l'articolo, indicare il riferimento al listino ed i relativi prezzi, percentuali etc etc e per ogni articolo hai immediatamente una visione di insieme di tutti i listini di cui fa parte e vedi tutti i prezzi e puoi mettere agevolmente l'articolo in promozione ed hai un database un pochino più leggero ma le query potrebbero essere più lente (in teoria, in pratica a meno che tu non abbia oltre i 100 mila record non noti niente) e diventa un pochino più complicata la gestione delle relazioni a livello di tabelle con i clienti e la creazione delle query, ma nulla di trascendentale. A livello visivo, sopratutto in fase di immissione è un po' come un foglio di excell, ma limitato al singolo articolo.
Puoi inoltre agevolmente creare listini personalizzati, sopratutto per gli articoli in promozione, visto che non faresti altro che creare un nome listino "promozione" e poi andare sui singoli articoli e assegnarli quel listino oppure, se crei ad esempio un listino con il prezzo basato sulle quantità di acquisto (da1 a 20) (da 11 a 20) etc etc puoi imputare ad ogni singolo prodotto il relativo prezzo, visto che il prezzo fa parte dell'articolo e non del listino
con la seconda, immetti il nome degli undici listini, ma per ognuno dei listini devi ripetere l'immissione degli articoli (il loro riferimento ID) il database fisicamente tenderà ad essere più pesante a livello di dimensioni, perchè per ogni listino che tu crei, avrai 350 riferimenti che si ripetono, uno per ogni articolo e almeno secondo la mia logica, diventa più difficile apportare delle personalizzazioni ai prezzi per i singoli o gruppo di articoli, perchè o vengono previsti in fase di progettazione e quindi si aggiunge un campo per ogni personalizzazione, oppure devi creare di volta in volta un nuovo listino. Per quanto riguarda poi gestione delle query, e relazioni, non è che poi cambi molto alla prima ipotesi.
Per quanto riguarda invece la personalizzazione degli articoli, con extra sconti, promozioni o altro penso che questa parte sia meglio gestirla a livello di preventivo, visto che per logica, penso che una promozione o un particolare sconto sia diretto ad un cliente o fascia di clienti, in un determinato periodo di tempo limitato e quindi non necessariamente deve far parte di un listino prezzi.
Per quanto mi riguarda preferisco la prima soluzione, ma come sempre, aspetto i suggerimenti ed i consigli degli altri.