ARGOMENTO: La Funzione del DDT

Riporto qui un'interessante discussione iniziata su github perché la ritengo di carattere generale. Una discussione più' approfondita andrebbe troppo oltre lo scopo di quella discussione incentrato sullo sviluppo di una funzione extra per la v8.

github.com/OCA/l10n-italy/issues/304#issuecomment-283320866

La domanda che vi pongo e mi pongo è: quali informazioni deve contenere un DDT?

Ovviamente l'analisi deve tenere in considerazione i processi cosi' come implementati nella v8 ed inferiori ed i nuovi processi di v9 e seguenti.

Lascio a voi la parola ma prima vorrei riportare una frase di enlightx che in se porta una grande verità:

"Che sia corretto o meno, è una prassi che purtroppo dobbiamo tenere in considerazione."

Il nocciolo del discorso sta proprio qui ... ".. una prassi" ... ma questa prassi è d'avvero necessaria?

Da parte mia vi posso portare l'esperienza di due installazioni attivate nel 2017 nel settore alimentare, quindi con gestione di lotti, date di scadenza, fatturazione basata sulle quantità spedite ed ovviamente fatturazione differita. In ambedue i casi dopo una serie di confronti (o scontri ) son riuscito a far abbandonare al cliente molte di queste prassi senza per questo venir meno a nessuna delle norme fiscali del nostro paese, a tutto vantaggio di una maggiori linearità dei processi e separazione dei ruoli. In tutta onestà pero' devo aggiungere che analogo risultato sarebbe stato molto più' difficile da raggiungere con la v8 ma buona parte di essi si.

A voi la parola.

Enlight ha detto "un'ovvietà" corretta che tutti noi, credo, dobbiamo condividere.

Il problema è nei confronti del cliente, che pretende informazioni che lo pongano al riparo da problemi fiscali e legali.
Tutti noi dobbiamo scontrarci con il clienti cui il commercialista dice che i DdT deve contenere questa o quella informazione.

Nello specifico, estendendo il concetto di enlight, credo che sul DdT sia possibile riportare anche prestazioni di servizio a patto che tali prestazioni siano integrative e necessarie ai prodotti del DdT stesso.

Esempio: prodotto con garanzia, potrebbe essere riportata la riga del codice prodotto e la riga del codice garanzia.

Non è ammissibile invece un DdT che contenga un pura prestazione d'opera.

I miei 2 cent

Come ho scritto qui ed altrove .... discussione interessante e spero lo diventi ancora di più' .....

Dal mio punto di vista considero un "cliente" come un "paziente" ....

Cosa vuole il cliente va tenuto in considerazione ma fino ad un certo punto, le unico cose dalle quali non è possibile prescindere sono:

a ) Le esigenze di business
b ) Le (purtroppo) norme fiscali

Qualunque sistema che rispetti le caratteristiche a,b è idoneo ad essere utilizzato ... può' non piacere al cliente, ed in quel caso sceglierà altro, ma è un qualcosa di soggettivo, l'oggettività sta nel fatto che il sistema sia idoneo.

In questi anni ho raccolto le richieste più' assurde, e nei primi tempi le ho anche accolte salvo poi pentirmi della scelta fatta.

Non condivido in toto il pensiero di Fabien per il quale è l'utente che deve adeguarsi ad Odoo ... ma in molti casi è cosi'. Odoo ha i suoi pregi ed i suoi difetti ... ti piace o non ti piace ... non è possibile trasformare le mele in pere e viceversa.

Sul DDT vanno messe le informazioni minime che le norme fiscali impongono, ne una di più' ne una di meno indipendentemente da quello che vuole il cliente. Se non gli sta bene esistono mille altri software, fortunatamente, che può' scegliere.

Il DDT è un "orpello" alle funzionalità base non può' stravolgerne i processi pena un sistema scarsamente manutenibile.

Se mi si chiede la fatturazione del DDT ... rispondo che non è possibile
Se mi si chiede prezzi sul DDT ... rispondo che non è possibile
Se mi si chiede servizi sul DDT .... rispondo che non è possibile
Se mi si chiede ..... rispondo che non è possibile

In tutti i casi il sistema risponde agli assiomi a,b quindi adeguato.

Ti serve la fatturazione differita, mi fatturi gli ordini (v9,v10) e la ottieni. Ti ostini a volere fatturare a partire dal DDT ... scegli altro consulente/prodotto.

Non voglio vantarmi, ma lo faccio , se oggi tutti i progetti che ho portato in produzione non hanno mai avuto problemi è perché non son mai venuto meno a questa regola che mi son dato. Personalizzazioni si ma solo se strettamente necessarie e mai per venir incontro ad abitudini consolidate ... il rischio è troppo alto e non me lo assumo.

sei stato fortunato allora
Comunque se nella maschera del DDT ci sono informazioni aggiuntive che non vengono stampate, che male fa?
Poi tieni conto che io i DDT e le fatture le faccio spesso, per cui modifico il sistema in base alla mia personale esperienza e necessità, sono un caso particolare che non fa testo.

Xergio ha scritto:
Fortunato ... non credo ... ho perso dei potenziali clienti per questo mio atteggiamento, ma preferisco perderlo il cliente che incasinarmi in astruse ed inutili personalizzazioni che poi gli devo manutenere.

Per il resto mi sa che mi sono spiegato male, per me sulle stampe ci può' stare di tutto (giusto ieri ho messo i termini di pagamento sul report DDT ). Idem per le informazioni a contorno specifiche per quell'oggetto e che nulla hanno a che fare con l'esterno.

Il problema nasce quando si voglio inserire informazioni che vanno ad influenzare i processi di odoo.

Faccio un esempio per essere più' chiaro ... prendo la richiesta delle modalità di pagamento sulla stampa.

Il report è stato implementato più' o meno cosi:

payment_term_ids = insieme di tutti i termini di pagamento presenti negli ordini riferiti ai picking

if len(payment_term_ids) > 1:
termini di pagamento come da ordini SOXX SOYY ....
else
termini di pagamento payment_term_ids

In questo modo la logica dei termini di pagamento rimane la dove deve stare (sull'ordine) e tutto il processo di fatturazione di odoo rimane inalterato.

Diversamente se avessi permesso di specificare sul DDT i termini di pagamento al momento della fatturazione degli ordini si combinava un casino.

Mettere i servizi sul DDT (copiarli) e permettere di specificare all'utente la quantità è altro problema ... se poi vado a rendicontare i servizi tramite timesheet tutto il processo ancora una volta si incasina.

Analogamente al caso precedente, nessuno mi vieta (se il cliente lo vuole) di inserire in calce al report del DDT la lista dei servizi presenti negli ordini correlati a questo DDT, ma stiamo parlando di report ... la gestione rimane nell'ordine.

Probabilmente anche io son un caso particolare ... anche se in senso opposto

Ciao gigi,
grazie della segnalazione.

Aggiungo una problematica che sembra velatamente emergere sia nel 3d citato che dalle risposte di molti presenti:

FATTURAZIONE DA DDT

Mi sembra che siamo tutti d’accordo che SE una azienda si è dotata di processi standard e procedure di acquisto (iso o non iso che siano) , il ddt dovrebbe essere la conseguenza di un ordine di vendita ottenuto con i dovuti processi.

Con uno sguardo a cosa succede proprio per gli ordini di vendita, è attualmente previsto (V10) che il processo standard “loro richiesta offerta → ns offerta → loro ordine SO→ ns conferma ordine SO” , si possa “abbreviare” inserendo direttamente l’ordine SO, e confermandolo al volo.

Analogamente, una proposta “operativa” per il DDT:

• Se il ddt è il risultato di un ordine SO, il processo di fatturazione attinge prezzi e condizioni dall’ordine (non dal ddt), ed eventualmente fattura il consegnato dal ddt se si è impostato il “consegnato” nei settings
• Se il ddt NON è il risultato di un ordine SO (perché manca), il processo di creazione ddt, propone di generare al volo un SO (come la descrizione di sopra), e in questo modo si riporta al workflow generale, e la fatturazione attinge prezzi e condizioni nuovamente dall’ordine.

Quindi nel modulo V10 Dtt (che è in corso di realizzazione) si potrebbe aggiungere un AUTOMATISMO che alla generazione del ddt

• richiede l’ordine SO da agganciare (se si vuole agganciare il ddt ad un ordine)
• genera l’ordine automaticamente (se non è ancora presente il suo SO)

cosa ne pensate ?