Ticket #35 (closed compito: sistemata)

Opened 4 years ago

Last modified 4 years ago

Cosa succede se un fornitore di un GAS non è un Produttore ?

Reported by: lfranc Owned by:
Priority: importante Milestone: Documento di analisi funzionale
Component: analisi Keywords:
Cc:

Description

Finora abbiamo dato per scontato (sia nella stesura del vocabolario, sia a livello di analisi) che i fornitori dei GAS siano esclusivamente produttori; non abbiamo considerato il caso in cui un GAS si approvvigioni da un soggetto economico che non produce tutti o alcuni dei Prodotti presenti nel suo ListinoProduttore. Alcuni scenari che possono presentarsi nella realtà:

  1. il Produttore è un rivenditore e/o un distributore di prodotti di terze parti
  2. un Produttore A "ospita" (senza ricarico) nel suo ListinoProduttore alcuni Prodotti di un Produttore B', in modo che ad esempio un GAS vicino al Produttore A posso accedere facilmente ai Prodotti di B.

A questo proposito, nascono alcune domande:
1) È appropriato adottare una terminologia più generale di "Produttore" per indicare un fornitore di un GAS (ad. es. "Fornitore") ?
2) Per un Prodotto, è opportuno prevedere un campo "Fornitore" oltre al campo "Produttore" ?


Change History

comment:1 in reply to: ↑ description Changed 4 years ago by dom_thual

Finora abbiamo dato per scontato (sia nella stesura del vocabolario, sia a livello di analisi) che i fornitori dei GAS siano esclusivamente produttori; non abbiamo considerato il caso in cui un GAS si approvvigioni da un soggetto economico che non produce tutti o alcuni dei Prodotti presenti nel suo ListinoProduttore. Alcuni scenari che possono presentarsi nella realtà:

Finora abbiamo fatto un analisi basata su dei criteri che sono alla base del consumo critico e che seguono le linee guide definite dentro "La carta nazionale dei GAS 1999".
FILIERA CORTA trattare direttamente con il produttore
KMO senza intermediazione
SOGGETTIVITA conoscere e valutare un produttore
BIOLOGICITA
UTILITA
...

  1. il Produttore è un rivenditore e/o un distributore di prodotti di terze parti

Abbiamo già parlato durante la fase di analisi delle forme aggregative lato produttore.
Nei fatti, esistono dei rivenditori e/o un distributore che adoperano già con i GAS:
Ad esempio MONDO SOLIDALE per il commercio equo con i produttori dell'altro mercato.
Ad esempio COOPERATIVA TERRA E CIELO che condivide i strumenti di lavorazione della pasta e raggruppa dei produttori che condividono la loro carta d'intenti e la biologicità.
Questi rivenditori sono considerati (abusivamente?) dei produttori.
Ma vengono valutati come se erano un semplice produttore che viene valutato con la stessa griglia di criteri etici.
Di conseguenza un ListinoProduttore, quando si tratta di una cooperativa, è implicitamente un raggruppamento di listini di varie produttori.

Questi raggruppano di produttori hanno sempre uno scopo. Sia per condividere delle linee di trasformazione o dei macchinari costosi, sia perché evolvono all'interno
di un contesto complesso (economia internazionale). In genere, questi raggruppamento sono effettuati con certe regole o scopo.

Pero dobbiamo evitare le cattive pratiche:
Alcuni produttori hanno confluito i loro prodotti in un unico listino solamente per presentare una bancarella che copre un ampia gamma. Fanno associazione per fare leva e/o per presentare una offerta più completa. Alcuni si mettono in gruppo per affrontare l'economia e la distribuzione organizzata. Hanno anche ragione di farlo quando davanti a loro l'interlocutore non è un DES. A volta le associazione di settore raggruppano produttori di varie sensibilità. A volta sono raggruppamenti di produttore solo a scopo di lucro e non per ragione etiche.
Ma se un produttore intende vendere in filiera corta, sulla piattaforma DES, le regole non sono uguale. Lui deve assimilare come funziona questa modalità organizzativa che parte dal basso.
Lo deve capire prima di presentarci come rappresentante legale di gruppo di produttore.

Adesso si tratta di distinguere tra Associazione eticamente orientate ed Associazione a scopo di lucro o di semplice logistica.
il tipico esempio e quello dell'orto-frutta. In questo caso, il DES non deve accorpare un raggruppamento di produttori ma dovrebbe valutarli UNO ad UNO. Anche se sono vicino di campo.
Di solito ciascun produttore dispone della sua partita IVA e l'associazione serve solo a scopo pratici.

Impariamo ad conoscersi:
I nostri criteri ci impegnano a conoscerli tutti. Di valutarli uno ad uno. Di inserirli con voce separate nella banca dati.
Vogliamo sapere chi produce quali prodotti quando è possibile.
I nostri criteri chiedono al produttore di non prendere roba che non è della sua produzione se per caso gli ordini sono superiore alla sua raccolta.
Il produttore deve produrre. Se questo produttore fa le Fragole (Marco) e rispetta i criteri allora apriamo ordini su di lui. Se pero Marco mi dice che con i suo amici possiamo anche avere prugne ed susine. Allora non si decide subito di incorporare nel listino di Marco i prodotti dei suoi colleghi di fiducia (cattiva pratica). In primo luogo, il DES deve incontrare questi altri produttori, e valutarli. Se non hanno un gestione di pagamento centralizzato NON ci deve aggregare i prodotti sotto il listino di un produttore. magari si crea altre schede, con relativi listini. Soltanto quando si apre un ordine su di uno si apre anche sugli altri: Coordinamento, logistica.
Non è perché questi produttori sono già associati tra di loro, e definiscono un sistema di reputazione al livello di produttore, che tutti possono partecipare al DES.

In sostanza: L'accettazione dì un produttore che fa parte di un associazione non include di fatto gli altri produttori della sua associazione.
Un fornitore è rappresentato dal unione di produttori, raggruppati con certi criteri, che condividono un centro di pagamento.

  1. un Produttore A "ospita" (senza ricarico) nel suo ListinoProduttore alcuni Prodotti di un Produttore B', in modo che ad esempio un GAS vicino al Produttore A posso accedere facilmente ai Prodotti di B.

Utilità:
C'è da chiedersi se queste forme aggregative sono necessarie o no al DES.
Alcune sono obbligatorie. Speso sulle categorie merceologiche tipo pasta, fair trade...
Pero alcune forme aggregative già esistente possono non essere accettate.
Il DES può ritenere solo un produttore dell'associazione e non partecipare al listino aggregativo dell'associazione di settore.
Un DES, un GAS o altre forme aggregative della domanda (consumatori finali), cercano loro di COSTRUIRE il paniere pieno. Non il contrario.

La "facilita"
E il DES che fa il listino aggregativo, impilando OrdineProduttore. Solo l'organizzazione e la pianificazione logistica del DES permette una accesso efficiente agli prodotti e alla loro consegna. e la "facilita" che si allontana della soggettività e ci va convergere verso il mondo del supermercato.

Non è un problema di "senza ricarico" quanto un problema soggettivo.
Se un produttore non la produce questa merce, no c'è a priori ragione perché lui si metta a fare il distributore per gli altri. Va contro la filiera corta perché sta già diventando un intermediario.
La retina GAS, a priori, non lui chiede questa cosa. Un conto è che dei produttori associati si impongono la loro associazione. E un altro conto se un produttore, conosciuto dal DES, informa il DES dicendo "Guarda conosco questo questi altri produttori, tra l'altro operiamo già insieme, e il mio vicino, e un amico, andate a vederli perché credo che potrebbero partecipare al DES. Quando il GAS ordina, recupero io i loro prodotti e ve li portò".

Normalmente la situazione è
OrdineProduttore su Produttore A --> ListinoProduttoreA
OrdineProduttore su Produttore B --> ListinoProduttoreB
Consegna lo stesso giorno (pianificazione GAS) e porta la merce il Produttore A senza ricarico

Logistica:
Se un produttore, quando consegna, può andare a prendere i prodotti di altri produttori, il buon senso fa si che si aprono gli ordini contemporaneamente (il motore in realtà).
La soluzione facile, che fa gola, di creare una scheda unica per avere subito un listino aggregativo è da scartare come cattiva pratica.
I GAS, perché appunto conoscono i produttori, sanno che alcuni produttori hanno strette relazione o sono vicini. Quando si apre un ordine per uno si apre anche per l'altro. E un dato pratico che è già incluso nell'operatività dei GAS.
L'aspetto logistico può essere migliorato con la piattaforma.

Se Produttore A e Produttore B sono associato (cooperative, partita IVA unica) non esiste il concetto di "senza ricarico" perché il loro listino è unico.
La TERRA E CIELO non dispone di un listino produttore per ogni suoi soci. C'è un listino unico.

A questo proposito, nascono alcune domande:
1) È appropriato adottare una terminologia più generale di "Produttore" per indicare un fornitore di un GAS (ad. es. "Fornitore") ?

Non necessariamente. Proporrei di conservare la parola produttore. Anche perché dobbiamo sempre identificare una persona fisica per preservare la soggettività.
Ad esempio per MONDO SOLIDALE identifichiamo Massimo MOGIATTI. (come già discusso in analisi)
Questo "ospità", quando l'associazione è stata accettata dal GAS, non deve portare a cambiare la terminologia ma va semplicemente notificato dentro gli attributi del Produttore (questo produttore rappresenta un'associazione di produttore).
C'è sempre uno "che ci mette la faccia" --> il Produttore A

Abbiamo già parlato durante l'analisi di forme aggregative di produttori:

  • esiste il nome del soggetto: produttore o rappresentante legale
  • esiste il nome dell'azienda

Va SPECIFICATO a fianco la struttura dell'azienda definendo quale regime fiscale definisce l'azienda:

  • Azienda a conduzione famigliale
  • PIVA società di produttori
  • Cooperativa di produttori
  • ...

Ad esempio per la cooperativa TERRA E CIELO può apparire il nome di Bruno SEBASTIANELLI

La piattaforma Web deve valorizzare l'aspetto SOGGETTIVO (appare il nome di una persona + il nome dell'azienda)
prima della STRUTTURA ORGANIZZATIVA (attributo)
e prima ancora del MARCHIO (attributo)
Lo deve fare anche se nei fatti siamo davanti un fornitore.

La scheda produttore, nella parte anagrafiche della piattaforma, se si tratta di un fornitore e/o rivenditore, può elencare una lista di soggetti.

2) Per un Prodotto, è opportuno prevedere un campo "Fornitore" oltre al campo "Produttore" ?


???? preoccupazione pocca soggettiva!

In modalità soggettiva questa domanda non ha senso. Un prodotto non ha per attributo il suo padre.
Il funzionamento della piattaforma in modalità soggettiva implica che il gasista seleziona il produttore del suo interesse "Voglio comprare la pasta di TERRA E CIELO".
Al produttore selezionato, anche se è un fornitore, ed associato la sua lista di prodotti.
Magari in alto della pagina (sopra il listino prodotti associato)
oltre ad informare il gasista di:

  • Nome-Cognome produttore
  • Ragione sociale

Aggiungiamo le informazione:

  • Tipo impressa (fornitore, distributore)


In modalità flat: se funzioni a listino?
per ogni prodotti si fa viaggiare la scheda produttore come attributo?
In questa modalità ci importa queste informazione?
Faccio difficoltà ad analizzare. A grande linee direi di non mostrare i dati del produttore.
"Voglio comprare della pasta". Non interessa a priori al gasista che la pasta sia di TERRA E CIELO, CAMPO, LA SALVIA o altre.
è utile mostrare informazione aggiuntive sul produttore quando sembra che a priori non interessa manco il nome? è sufficiente la ragione sociale?
I gasisti vedono una lista di prodotti e filtrano per categoria merceologica.
In questa modalità, se vuoi sapere chi produce cosa, vai a consultare la parte anagrafica della piattaforma web.

Last edited 4 years ago by dom_thual (previous) (diff)

comment:2 follow-up: ↓ 3 Changed 4 years ago by lfranc

Cerco di sintetizzare dal chilometrico ;-) post di Dominique quelli che mi sembrano essere gli elementi salienti:

  • i valori fondanti dei GAS portano ad evitare, quando possibile, ogni forma di intermediazione distributiva;
  • nel rapporto con un fornitore, è fondamentale la conoscenza diretta, de visu;
  • l'aggregazione dell'offerta deve avvenire prevalentemente lato GAS, non lato Produttore ("deve essere il GAS a sforzarsi di riempire il suo paniere" ); la piattaforma informatica ha l'obiettivo di rendere più efficiente questo processo.

Premesso che (ovviamente) condivido questi principi, io sostengo invece che distinguere tra Fornitore e Produttore possa essere utile. Alcune argomentazioni al riguardo:

  • come giustamente ricorda Dominique, di fatto alcuni importanti fornitori dei GAS (Mondo Solidale, la Terra e il Cielo) non sono produttori puri (anzi, Mondo Solidale è un "rivenditore puro"); non possiamo non tenere conto di questo fatto;
  • con la distinzione tra Fornitore e Produttore abbiamo a disposizione uno strumento (seppur rudimentale) di tracciamento della filiera produttiva. Ad esempio, nel caso della cooperativa La Terra e il Cielo, i Gasisti potrebbero vedere quali sono le produzioni proprie e quali invece no; mi sembra uno strumento utile, che rafforza la "soggettività"
  • con questa distinzione, inoltre, rendiamo il nostro software più flessibile senza un aggravio eccessivo dei costi di implementazione
  • per la cronaca, anche  GASdotto usa la locuzione "gestione fornitori" invece che "gestione produttori" nel' interfaccia dell'applicazione (non che sia un'argomentazione risolutiva, ma dimostra che non si tratta di una proposta peregrina)

Ho anche cercato di formalizzare questa distinzione tra Produttore e Fornitore a livello di modello dati; qui trovate una bozza (in particolare, cfr. Prodotto vs StockFornitore).

comment:3 in reply to: ↑ 2 ; follow-up: ↓ 4 Changed 4 years ago by dom_thual

Replying to lfranc:

Cerco di sintetizzare dal chilometrico ;-) post di Dominique quelli che mi sembrano essere gli elementi salienti:

  • i valori fondanti dei GAS portano ad evitare, quando possibile, ogni forma di intermediazione distributiva;
  • nel rapporto con un fornitore, è fondamentale la conoscenza diretta, de visu;
  • l'aggregazione dell'offerta deve avvenire prevalentemente lato GAS, non lato Produttore ("deve essere il GAS a sforzarsi di riempire il suo paniere" ); la piattaforma informatica ha l'obiettivo di rendere più efficiente questo processo.

Premesso che (ovviamente) condivido questi principi, io sostengo invece che distinguere tra Fornitore e Produttore possa essere utile. Alcune argomentazioni al riguardo:

  • come giustamente ricorda Dominique, di fatto alcuni importanti fornitori dei GAS (Mondo Solidale, la Terra e il Cielo) non sono produttori puri (anzi, Mondo Solidale è un "rivenditore puro"); non possiamo non tenere conto di questo fatto;

I GAS distinguono già i produttori per tipologia.
E già efficiente senza andare a complicare il modello che avrebbe come solo conseguenza di scrivere chilometri di codice in più.
I GAS come INPUT hanno bisogno di una faccia ed un listino.

  • con la distinzione tra Fornitore e Produttore abbiamo a disposizione uno strumento (seppur rudimentale) di tracciamento della filiera produttiva. Ad esempio, nel caso della cooperativa La Terra e il Cielo, i Gasisti potrebbero vedere quali sono le produzioni proprie e quali invece no; mi sembra uno strumento utile, che rafforza la "soggettività"

La complessità della filiera corta non è uno scopo del gestionale. Fare un CRM è un impressa.
Nessun GAS desidera registrare i soci di un rivenditore o di una cooperativa. Terra e Cielo ne conta 150 (se non sbaglio). Sarebbe ingestibile. E la banca dati sarebbe sempre de sincronizzata cosi come lo sono le banche dati sugli GAS.
RIPETO: di fronte ad una aggregazione, I GAS vogliono sapere quale criteri è alla base di questa aggregazione. In altre parole: quale è la carta d'intenti di questa associazione.

Credo pero che ci siamo allontanati della soggettività.

I GAS fanno delle cose semplice:

Un GAS Incontra un soggetto.
Questo soggetto rappresenta dei criteri.
Questo soggetto vende una lista di prodotti.
Il GAS compra dei prodotti di questo soggetto.
Questo soggetto porta i prodotti ordinati in sede.

Il soggetto può essere chiunque, fare qualsiasi mestiere ed essere più o meno strutturato.
Il soggetto può fare direttamente o indirettamente i prodotti.
I GAS NON intendono entrare in dettaglio nella complessità lavorativa, fiscale, aggregativa del soggetto.
I GAS vogliono sapere che tipo è: sei autonomo?, hai la PIVA?, siete in tanti? sei da solo? come si chiama quello che rappresenti?
Un GAS non è un impressa.
Non esiste un gasista pagato per tenere un stock.
Non esiste un produttore che aggiorna i stock a disposizione del GAS.

  • con questa distinzione, inoltre, rendiamo il nostro software più flessibile senza un aggravio eccessivo dei costi di implementazione

PRIMA:
tabella Produttore
tabella Prodotto
tabella VoceDiOrdine:

ordine_produttore -> OrdineProduttore

DOPO:
tabella Produttore
tabella Fornitore (mancava!)
tabella Prodotto
tabella StockFornitore (?)
tabella !StockFornitoreGAS (?)
tabella VoceDiOrdine:

ordine_produttore -> OrdineProduttore
stock -> !StockFornitoreGAS (?)

...

Non so dove nasce la flessibilità pretesa ma a primo occhio è pesante.
Per il gestionale è più che sufficiente il campo TipoProduttore come attributo della tabella Produttore.

DOPO:
tabella Produttore

Tipo produttore # PRODUTTORE|ASSOCIAZIONE|FORNITORE|RIVENDITORE|SITO WEB|FARMER MARKET|NEGOZIO|AZIENDA|PRIVATO|DES|HUB|CENTRALE D'ACQUISTO|MERCATO ITICO|

tabella Prodotto
tabella VoceDiOrdine:

ordine_produttore -> OrdineProduttore

(

  • per la cronaca, anche  GASdotto usa la locuzione "gestione fornitori" invece che "gestione produttori" nel' interfaccia dell'applicazione (non che sia un'argomentazione risolutiva, ma dimostra che non si tratta di una proposta peregrina)

Cattiva pratica?
Produttore è più soggettivo che Fornitore. Ma se è un problema terminologico, per evitare le complicazione, possiamo dire VENDITORE. Personalmente non opterei: trovò VENDITORE convenzionale cosi come carrello. Ma se "rende meglio l'idea" perché no. Apriamo un voto.

La provincia di MACERATA e la REES usano il termine Produttore anche se partecipano dei fornitori. Non vuole essere un argomento ma dimostra che siamo allineati con la rete di economia solidale locale. E un fatto culturale.

Ho anche cercato di formalizzare questa distinzione tra Produttore e Fornitore a livello di modello dati; qui trovate una bozza (in particolare, cfr. Prodotto vs StockFornitore).

L'introduzione di queste tabelle non è giustificabile. Mancano argomenti o spiegazioni. Lorenzo non fare troppo sintetico e spieghi più in dettaglio come sei arrivato a questa conclusione di creare altre tabelle. Dalla riunione fatti in provincia, ho avuto la confermazione che il modello fin cui va più che bene per il progetto.
Adesso la tua trascrizione sulla bozza modifica la struttura dati, il vocabolario, il modello.
Che cosa vi allarma?

Il modello deve permettere agli GAS di comprare prodotti da un soggetto.
Non intende essere un e-commerce e neanche un CRM.

Cosa succede se un fornitore di un GAS non è un Produttore ?
è solo una questione di tipologia. è un problema ANAGRAFICO. Non è un problema di WorkFLow. La scheda anagrafica del produttore esplicita tutto quello che c'è dietro il soggetto.

comment:4 in reply to: ↑ 3 ; follow-up: ↓ 5 Changed 4 years ago by lfranc

I GAS distinguono già i produttori per tipologia.
E già efficiente senza andare a complicare il modello che avrebbe come solo conseguenza di scrivere chilometri di codice in più.

Se guardi bene le strutture dati e/o il vocabolario, l'unica complicazione introdotta al modello è quella di aggiungere una chiave esterna all'entità (o tabella, se preferisci) StockFornitore, entità che esisterebbe comunque (magari ribattezzata come StockProduttore) anche nel caso in cui non si faccia distinzione tra chi produce e chi fornisce un determinato Prodotto. Tra l'altro, il fatto che questo attributo esista nel modello, non implica che vada utilizzato da subito, o in ogni caso; è solo un appiglio che consente una gestione più flessibile e generale nel caso in cui se se senta il bisogno. In definitiva: nessuno pericolo di "chilometri di codice in più" (tra l'altro, non sapevo che il software si misurasse in Km :-))

La complessità della filiera corta non è uno scopo del gestionale. Fare un CRM è un impressa.

E chi vuol fare un CRM ? Non certo io ! ;-)

Nessun GAS desidera registrare i soci di un rivenditore o di una cooperativa. Terra e Cielo ne conta 150 (se non sbaglio). Sarebbe ingestibile.

Infatti, questo sarebbe (eventualmente) compito del Fornitore, se ritenesse utile indicare ai GAS alcune informazioni in più nell'ottica di una maggiore trasparenza; nel caso in cui, invece, non fosse interessato o ritenesse lo sforzo eccessivo, potrebbe tranquillamente evitare di farlo (impostando adeguatamente i valori di default).

RIPETO: di fronte ad una aggregazione, I GAS vogliono sapere quale criteri è alla base di questa aggregazione. In altre parole: quale è la carta d'intenti di questa associazione.

E questo che c'entra ? Sono problematiche ortogonali, a mio parere.

Credo pero che ci siamo allontanati della soggettività.

Scusa, ma a mio parere dovremmo cercare di evitare di argomentare sulla base di "questo è soggettivo, questo no"; cerchiamo di rimanere sul punto, argomentando in modo circostanziato e concreto. La soggettività è un concetto importante, ma cerchiamo di non abusarne !

I GAS fanno delle cose semplice:

Un GAS Incontra un soggetto.
Questo soggetto rappresenta dei criteri.
Questo soggetto vende una lista di prodotti.
Il GAS compra dei prodotti di questo soggetto.
Questo soggetto porta i prodotti ordinati in sede.

Il soggetto può essere chiunque, fare qualsiasi mestiere ed essere più o meno strutturato.
Il soggetto può fare direttamente o indirettamente i prodotti.

Ok, ma questo che c'entra ? Qui si sta discutendo se sia opportuno distinguere tra Fornitore e Produttore e introdurre questa distinzione nel modello dati.

I GAS NON intendono entrare in dettaglio nella complessità lavorativa, fiscale, aggregativa del soggetto.

Infatti, non devono farlo, ma potrebbero volerlo fare (se la filiera corta è un obiettivo centrale per i GAS, avere qualche informazione in più sui passaggi dei Prodotti potrebbe costituire un valore aggiunto, o no ?)

Un GAS non è un impressa.

Su questo non ci piove ;-)

Non esiste un gasista pagato per tenere un stock.

E chi gli chiede di farlo ?

Non esiste un produttore che aggiorna i stock a disposizione del GAS.

Beh, qui non sono d'accordo; anche nello scenario più semplice, il Produttore può dire "questo c'è, questo no"; si tratta quindi di una gestione dello stock, anche se solo a livello qualitativo.

  • con questa distinzione, inoltre, rendiamo il nostro software più flessibile senza un aggravio eccessivo dei costi di implementazione

PRIMA:
tabella Produttore
tabella Prodotto
tabella VoceDiOrdine:

ordine_produttore -> OrdineProduttore

DOPO:
tabella Produttore
tabella Fornitore (mancava!)
tabella Prodotto
tabella StockFornitore (?)
tabella !StockFornitoreGAS (?)
tabella VoceDiOrdine:

ordine_produttore -> OrdineProduttore
stock -> !StockFornitoreGAS (?)

...

Non so dove nasce la flessibilità pretesa ma a primo occhio è pesante.

Qui c'è un malinteso, e in parte la colpa è mia; infatti la riorganizzazione delle strutture dati è slegata quasi completamente dalla questione Fornitore vs Produttore; le "nuove" entità introdotte (StockFornitore, StockFornitoreGAS, VoceDiOrdine) in realtà erano già presenti sotto forma dei vari Listini*; infatti, come risultata da qui i listini non vengono tradotti in oggetti a livello di database, ma solo i loro "atomi". Il numero di entità introdotte non mi sembra poi eccessivo, consideratà la complessità dell'applicazione; date un'occhiata a  quante tabelle ci sono in BioEquo, ad es. ! (anche se molte di queste mi sembrano relative a funzionalità non "di base").

Produttore è più soggettivo che Fornitore.

È un assioma della teoria dei GAS ? ;-)

La provincia di MACERATA e la REES usano il termine Produttore anche se partecipano dei fornitori. Non vuole essere un argomento ma dimostra che siamo allineati con la rete di economia solidale locale. E un fatto culturale.

Ok, non vorrei fossilizzarmi troppo sulla questione terminologica. Il nodo da sciogliere è se vogliamo o meno tenere traccia di chi produce effettivamente un Prodotto o no.

Ho anche cercato di formalizzare questa distinzione tra Produttore e Fornitore a livello di modello dati; qui trovate una bozza (in particolare, cfr. Prodotto vs StockFornitore).

L'introduzione di queste tabelle non è giustificabile. Mancano argomenti o spiegazioni.

Hai ragione, ma pensavo di lasciare le spiegazioni alla prossima riunione.

Lorenzo non fare troppo sintetico e spieghi più in dettaglio come sei arrivato a questa conclusione di creare altre tabelle.

Il motivo è semplice: ho cercato di riorganizzare e semplificare (a livello di modello dati) le definizioni del Vocabolario relative alla gestione dei Listini e degli Ordini. Il risultato sono le seguenti entità:

  • Fornitore (o Produttore, se preferite)
  • Prodotto
  • StockFornitore (o StockProduttore, se preferite)
  • StockFornitoreGAS (o StockProduttoreGAS, se preferite)
  • OrdineProduttore
  • VoceDiOrdine
  • OrdineGasista

La logica sottostante è quella che ho già esposto altre volte: cerchiamo di creare un modello quanto più generale e flessibile possbile senza introdurre una complicazione eccessiva. Credo che il tutto il lavoro che faremo sul Modello poi ci ritornerà sotto forma di minori mal di testa nella scrittura del codice.

Se avete una proposta migliore, sono tutt'orecchie ;-)

comment:5 in reply to: ↑ 4 ; follow-up: ↓ 6 Changed 4 years ago by dom_thual

  • Fornitore (o Produttore, se preferite)
  • Prodotto
  • StockFornitore (o StockProduttore, se preferite)
  • StockFornitoreGAS (o StockProduttoreGAS, se preferite)
  • OrdineProduttore
  • VoceDiOrdine
  • OrdineGasista

La logica sottostante è quella che ho già esposto altre volte: cerchiamo di creare un modello quanto più generale e flessibile possbile senza introdurre una complicazione eccessiva. Credo che il tutto il lavoro che faremo sul Modello poi ci ritornerà sotto forma di minori mal di testa nella scrittura del codice.

Se avete una proposta migliore, sono tutt'orecchie ;-)

Ok ho capito meglio quello che intendi. Infatti è valida la tua proposta di struttura dati per il concetto di 'fornitore'.
Ti dico subito che è poco pratico, ma condivido il tuo pensiero ed infatti portà, in teoria, ad una plus value sulla rintracciabilità.

  • Prodotto
    • produttore -> Produttore (un prodotto è associato ad un produttore)
  • StockProduttore
    • fornitore -> Produttore (il canale distributivo)
    • prodotto -> Prodotto

per farlo semplice e possibile fare anche così:

  • Prodotto
    • produttore -> Produttore (un prodotto è associato ad un produttore)
    • fornitore -> Produttore (il canale distributivo)

Capisco il problema terminologico che ti eri posti. Prendi per buono che i fornitori dei GAS sono al 80% i produttori stessi. per questo preferisco 'Produttore'
Tieni in mente che quando abbiamo da fare con un fornitore, di solito è quasi impossibile di risalire al produttore stesso!
prendi il caso del cioccolato di mondo solidale (indica il paese d'origine e l'associazione di produttori) o le lenticchie piccole di montagna di TERRA E CIELO. Più che un produttore è una partita e non viene scritto sul prodotto l'agricoltore (ansi le raccolte potrebbe essere mischiato sul silo? devo chiedere a LORIS).

Domanda: Quando il fornitore e un rivenditore quale valore prende il campo produttore se non lo conosciamo?

anonimo?
il fornitore stesso?
è opzionale!!!!!

Cioè in fin fine ti ritroverai sul database con 98% dei prodotti con

  • Prodotto
    • nome = X
    • produttore -> Produttore A
    • fornitore -> Produttore A

Il quale produce un risultato poco convincente.
Per altro condanna nella scheda anagrafica del prodotto di inserire in pratica questa informazione supplementare.
In ogni modo non esistono tabelle diverse (Fornitore e Produttore). Le caratteristiche sono uguale per quello che riguarda i fabbisogni dei GAS.

Proposta: non modificare il modello già stabilito, ridurre il concetto di 'fornitore' ad un semplice campo nella tabella Produttore.

  • Prodotto
    • nome
    • produttore -> Produttore (un prodotto è associato ad un produttore)
    • um
    • prezzo
    • quantità
    • confezionamento
  • Produttore
    • tipo-produttore # PRODUTTORE|ASSOCIAZIONE|FORNITORE|RIVENDITORE|SITO WEB|FARMER MARKET|NEGOZIO|AZIENDA|PRIVATO|DES|HUB|CENTRALE D'ACQUISTO|MERCATO ITICO|


Entità StockProduttore

Non capisco ancora la plus value che porta. Spieghi meglio la nascita di questa entità? Vuoi arrivare ad un template? o era solamente per separare il concetto di Produttore e fornitore?
Definisci nel vocabolario che le altre proprietà sono "informazioni non intrinseche" al prodotto. Con quale criteri applichi questa regola?
Perché um e prezzo sono separati?

  • Prodotto
    • nome
    • um
  • StockProduttore
    • prodotto -> Prodotto
    • disponibilità (SI/NO)
    • prezzo
    • quantità
    • confezionamento

L'idea è interessante per non duplicare il nome del prodotto
o fare una cosa del genere (template):

  • StockProduttore
    • prodotto <--> Prodotto

In pratica vuoi arrivare a qualcosa nel genere?

  • ProdottoA (Pasta al farro)
  • StockProduttore1
    • prodotto -> ProdottoA (Confezione di 500gr)
  • StockProduttore2
    • prodotto -> ProdottoA (pacco risparmio di 3kg)


A priori non sono contrario, pero a conti fatti non so come migliora veramente il sistema.
Propongo tuttora

  • Prodotto
    • SottoCategoria Merceologica
    • nome
    • disponibilità (SI/NO)
    • um
    • prezzo
    • quantità
    • confezionamento

A voce lo spieghi meglio domani.

Prodotto multi produttore?

Magari se vogliamo fare tendere il modello verso qualcosa del genere:

  • Prodotto
    • nome
    • produttore <- Produttore (un prodotto associato ad uno o più produttori)

e quindi richiederebbe un altra entità per personalizzare un prodotto generale: StockProduttore appunto

Questa versione permetterebbe di evitare che 2 prodotti portano lo stesso nome:

  • Farina integrale
    • MORETTI
  • Farina integrale
    • TERRA E CIELO

Pero che porta di meglio?
A livello statistico e meglio curare bene la categoria merceologica.

PDS

Dopo dobbiamo essere chiari che siamo parlando di Produttore (entità di retina) e non di PDS (patto di solidarietà, cioè l'associazione specifica tra un GAS e un Produttore)
Anche il PDS legato al prodotto potrebbe avere proprietà e quindi nascerebbe una nuova entità. Pero non ne ho identificato un utilità per il step 1.
L'utilità è di mettere la disponibilità a questo livello. gestione prodotti indesiderati?

  • ProdottoPDS
    • prodotto -> Prodotto
      • pds -> PattoDiSolidarieta

-> GAS
-> Produttore

  • disponibilità (SI/NO) (ad es. il GAS vegetariano nasconde a tutti gasisti i prodotti a base di carne)

Sarebbe in questa entità che potrebbe prendere forma un listino prezzo customizzato dal GAS.

Lorenzo: quando parli di StockProduttore lo intendi al livello di retina? non di GAS?

PRODUTTORE

  • Produttore
  • uuid # P.IVA/C.F.

tenderei a:

  • Produttore
  • uuid produttore
  • codice # P.IVA/C.F.

Speso quando si crea una scheda non si conosce subito P.IVA/C.F.
E più soggettivo di creare una scheda conoscendo nome cognome senza essere bloccato da un dato istituzionale.

comment:6 in reply to: ↑ 5 Changed 4 years ago by fero

Premetto che mi piace la soluzione proposta di associare ad un prodotto un produttore e un fornitore.
Gestisce in modo semplice ed efficace la situazione Mondo Solidale che in questo primo step non si presenta perché siamo sulla filiera del BIO, ma è sicuramente da prevedere per una gestione completa degli ordini dei GAS.

L'altra dovuta e doverosa premessa è che LE SCELTE POLITICHE NON CI RIGUARDANO. O meglio, ottimo far notare le problematiche ideologiche o di cattive pratiche, ma la posizione finale su questo la deve prendere la REES. Per questo ho aperto il ticket 45 e ho aperto anche un nuovo tipo per i ticket che è politico-strategico.

Per il resto rispondo inline.

Replying to dom_thual:

  • Fornitore (o Produttore, se preferite)
  • Prodotto
  • StockFornitore (o StockProduttore, se preferite)
  • StockFornitoreGAS (o StockProduttoreGAS, se preferite)
  • OrdineProduttore
  • VoceDiOrdine
  • OrdineGasista

La logica sottostante è quella che ho già esposto altre volte: cerchiamo di creare un modello quanto più generale e flessibile possbile senza introdurre una complicazione eccessiva. Credo che il tutto il lavoro che faremo sul Modello poi ci ritornerà sotto forma di minori mal di testa nella scrittura del codice.

Questo credo e spero non sia più necessario ripeterlo.

una plus value sulla rintracciabilità.

  • Prodotto
    • produttore -> Produttore (un prodotto è associato ad un produttore)
  • StockProduttore
    • fornitore -> Produttore (il canale distributivo)
    • prodotto -> Prodotto

per farlo semplice e possibile fare anche così:

  • Prodotto
    • produttore -> Produttore (un prodotto è associato ad un produttore)
    • fornitore -> Produttore (il canale distributivo)

è più appropriato nello StockProduttore (che io chiamerei StockFornitore) perché un produttore produce delle cose che poi possono essere consegnati da molti.

Capisco il problema terminologico che ti eri posti. Prendi per buono che i fornitori dei GAS sono al 80% i produttori stessi. per questo preferisco 'Produttore'

Meglio ancora per me che siano evidenziati i 2 termini.

Domanda: Quando il fornitore e un rivenditore quale valore prende il campo produttore se non lo conosciamo?

anonimo?
il fornitore stesso?
è opzionale!!!!!

Cioè in fin fine ti ritroverai sul database con 98% dei prodotti con

  • Prodotto
    • nome = X
    • produttore -> Produttore A
    • fornitore -> Produttore A

Il quale produce un risultato poco convincente.

Per me no: "prodotti e forniti da tizio".

Domanda: fornitore è sinonimo di distributore per voi? Per me a questo punto sì.

Per altro condanna nella scheda anagrafica del prodotto di inserire in pratica questa informazione supplementare.

Se lo si vuole... dato che è opzionale.

In ogni modo non esistono tabelle diverse (Fornitore e Produttore). Le caratteristiche sono uguale per quello che riguarda i fabbisogni dei GAS.

Su questo concordo.

Proposta: non modificare il modello già stabilito, ridurre il concetto di 'fornitore' ad un semplice campo nella tabella Produttore.

  • Prodotto
    • nome
    • produttore -> Produttore (un prodotto è associato ad un produttore)
    • um
  • prezzo
  • quantità
  • confezionamento

Gli ultimi 3 campi vanno nello stock.

  • Produttore
    • tipo-produttore # PRODUTTORE|ASSOCIAZIONE|FORNITORE|RIVENDITORE|SITO WEB|FARMER MARKET|NEGOZIO|AZIENDA|PRIVATO|DES|HUB|CENTRALE D'ACQUISTO|MERCATO ITICO|

Per l'entità bisognerebbe trovare un termine che accomuni Produttore e Fornitore secondo me. Va bene il "tipo". Sui tipi specifici discutiamo.

Il fornitore è "chi fa la fattura?". I farmer market sono solo spazi a disposizione, non fanno la fattura. Quindi la disposizione di ordine a chi viene fatta? Al produttore o al fornitore? Secondo me qui bisognerebbe prevedere un altro campo "a chi va indirizzato l'ordine".

  • Caso Farmer Market --> al Produttore
  • Caso Fornitore che acquista e rivende --> al Fornitore


Entità StockProduttore

Non capisco ancora la plus value che porta. Spieghi meglio la nascita di questa entità? Vuoi arrivare ad un template? o era solamente per separare il concetto di Produttore e fornitore?
Definisci nel vocabolario che le altre proprietà sono "informazioni non intrinseche" al prodotto. Con quale criteri applichi questa regola?
Perché um e prezzo sono separati?

Perché um non varia mai, mentre il prezzo sì, la disponibilità sì... il confezionamento? Se no allora va in Prodotto, se sì invece va in StockProduttore

A voce lo spieghi meglio domani.

Ripeto: è la differenza tra Catalogo e Listino. Il Catalogo contiene gli articoli e le informazioni "intrinseche" (che non cambiano mai o raramente), il Listino contiene gli Stock ossia le informazioni variabili. Non ci torniamo sopra per piacere dato che è stato ampiamente approfondito.

Prodotto multi produttore?

Magari se vogliamo fare tendere il modello verso qualcosa del genere:

  • Prodotto
    • nome
    • produttore <- Produttore (un prodotto associato ad uno o più produttori)

e quindi richiederebbe un altra entità per personalizzare un prodotto generale:

Il "prodotto generale" non esiste. Non esiste l'elemento "farina integrale". Esiste farina integrale MORETTI appunto.

PDS

Dopo dobbiamo essere chiari che siamo parlando di Produttore (entità di retina) e non di PDS (patto di solidarietà, cioè l'associazione specifica tra un GAS e un Produttore)
Anche il PDS legato al prodotto potrebbe avere proprietà e quindi nascerebbe una nuova entità.

Non esiste il PDS legato al prodotto. il PDS è legato al Produttore. Che è quello a cui pago. Ma non è detto che sia quello che mi consegna la merce.

PRODUTTORE

  • Produttore
  • uuid # P.IVA/C.F.

tenderei a:

  • Produttore
  • uuid produttore
  • codice # P.IVA/C.F.

Speso quando si crea una scheda non si conosce subito P.IVA/C.F.
E più soggettivo di creare una scheda conoscendo nome cognome senza essere bloccato da un dato istituzionale.

Un id direi che ce lo abbiamo sempre e comunque. L'uuid può essere comunque unico, ma opzionale. Non so se conviene usare la PIVA o il CF come UUID io userei comunque un terzo campo che è derivato dalle altre informazioni del produttore.

comment:7 in reply to: ↑ description Changed 4 years ago by lfranc

Replying to lfranc:
Riassumendo quanto condiviso nel corso della discussione:

1) È appropriato adottare una terminologia più generale di "Produttore" per indicare un fornitore di un GAS (ad. es. "Fornitore") ?

SI, in quanto questa distinzione esiste sia a livello concettuale che nella pratica dei GAS.
Resta inteso che questa scelta terminologica si applica limitatamente all'analisi funzionale per la piattaforma web (uso interno al team di sviluppo); la terminologia da usare nel'interfaccia utente verrà discussa in un secondo momento.

2) Per un Prodotto, è opportuno prevedere un campo "Fornitore" oltre al campo "Produttore" ?

SI, in quanto questa scelta consente (ma non impone) ai Fornitori di indicare la provenienza di un Prodotto presente nel loro catalogo (e apre la strada al tracciamento della filiera produttiva).

comment:8 Changed 4 years ago by lfranc

  • Status changed from new to closed
  • Resolution set to sistemata
Note: See TracTickets for help on using tickets.