ARGOMENTO: LISTINI Acquisto-Vendita aziende al DETTAGLIO

Nel settore al dettaglio di PRASSI è previsto (quasi per ogni MARCA/fornitore)

• un listino vendita al pubblico (prezzi ivati) e consigliati dal produttore/fornitore stesso
• un listino di acquisto del fornitore (prezzi senza iva)

Ora ho verificato che Odoo prevede al creazione di specifici listini per fonirtori e clienti, con possibilità di VERSIONI “cronologiche” e di categoria/prodotto /Purchase→ configuration → pricelist e Sales → configuration → pricelist )

TUTTAVIA i listini in Odoo sono frutto di CALCOLI fatti su prezzi di acquisto/vendita;
calcoli tipo:
Pricelist- New → Create: Pricelist Versions → Create: Price List Items ->
Price Computation - > Based on (Cost Price, Public Price, Supplier price on product form)


INVECE nel mondo del dettaglio, ogni fonritore manda PERIODICAMENTE un file (..xls se fortunati) con codici ean/codiciprodotto/MOQ/datalancio/statoattivo/descrizione/…e i relativi prezzi aggiornati (di vendita e/o di acquisto).

In questi casi, i listini contengono prezzi ASSOLUTI, sia per l'acquisto che per la vendita (consigliati) .

Ora, questi tipi di listini PERIODICI NON mi sembrano i listini “calcolati” che Odoo propone nei menù
Purchase→ configuration → pricelist
Sales → configuration → pricelist

DOVE è possibile caricare questi listini PERIODICAMENTE,
e senza ovviamente SOVRASCRIVERE lo STORICO ?

forse ti serve:

github.com/OCA/product-attribute/tree/7....ricelist_fixed_price

però è da fare il porting a v8 ancora, la PR la trovi qui:
github.com/OCA/product-attribute/pull/50

Grazie Davide.
Ma li conosci tutti i moduli in PR ?

La PR mi sembra bloccata su un constrain del db product product

Guadando la tabella product.product di esempio, una enormità di prodotti come
Boni oranges
Orange Butterfly
Lemon
Stringer
…
Cocacola
…
Pepsi

il campo default_code hanno vuoto… e li il constrain penso che vada a scatafascio ...
non so come faranno a farla passare i test
…. Il problema è che il modulo vuole un constrain sul campo defalt_code, ma proprio il dbase di esempio dei test, quel campo lo ha “duplicato” (ossia non unico) per un sacco di articoli…. Fallirà SEMPRE i test con QUEL dbase...

Nota tecnica…. approfitto per chiedere:
MA leggendo il README.rst del branck 8, si vuole ottenere l'effetto con un TRUCCO (dice proprio così)

non è ESATTAMENTE la stessa cosa se impostiamo SEMPLICEMENTE la formula di calcolo
in “Create: Price List Items” come

Price computation
Product.pricelist.item→base = Cost Price (qui non capisco in verità cosa mettere...)
Product.pricelist.item→ Price discout = 1
Product.pricelist.item → Price_surcharge = ILMOPREZZO

Ciòè imposto un listino fornitore "normale" come prezzo fisso azzerando la formula in modo "standard".
Cosa aggiunge il loro modulo allora ?

Cosa dici di mettere in Product.pricelist.item→base ?
Direi che va a zero sempre e comunque in ogni caso visto, che lo moltiplico per zero....
C'è qualche differenza logica che spinge su un prezzo o un altro ?

Vedo che quello non è il modulo che pensavo che fosse.
usavo un modulo che aveva fatto mi pare eLBati, ma non è quello.

Chissà se eLBati è in ascolto e ne sa qualcosa?

enlightx ha scritto: Lo ha riscritto meglio Pedro, ma l'obiettivo è identico