Non c'è un vero e proprio modo per gestire questo caso, ma ciò che potresti fare è impostare la politica di fatturazione su Milestone così che diventi fatturabile solo dopo che, manualmente, confermi la spedizione variando la quantità consegnata sull'ordine.

Un altro modo, forse più elegante, è passare per la fatturazione dei DDT.

Aggiunge step al flusso, ma consente di commettere meno errori

mesi fa ho risolto la stessa identica necessità estendendo la _get_invoiced della sale_order impostando 'invoice_status': 'no' se non c'è almeno un prodotto consegnato (prodotti con soline.product_id.invoice_policy == 'delivery' e soline.qty_delivered < 1)

Grazie dei chiarimenti molto utili, per adesso ho adottato la soluzione proposta da Davide, ovvero l'impostazione del servizio di spedizione come fattura il consegnato e impostato a "modifica manualmente le quantità nell'ordine". Il volume dei nostri ordini non è elevatissimo e l'addetto ha ricevuto le istruzioni per fare l'operazione dopo la validazione dei movimenti di magazzino dell'ordine. Certo, occorrerebbe un funzionamento dei prodotti associati ai metodi di consegna che renda le relative righe d'ordine fatturabili quando vengono validati i movimenti di magazzino dell'ordine (del tutto o in parte variabile nel caso di ordine con spedizioni multiple). Mi sembrerebbe una funzione non troppo evoluta, anzi per il livello di complessità che Odoo riesce a gestire la definirei quasi banale. Sinceramente quando ne ho rilevato l'assenza sono rimasto un po' sorpreso...

Hai 2 (forse 3) soluzioni e solo una di queste e' zero code. La prima, zero code, è lasciare che le spese vengano aggiunte alla conferma della spedizione. Questo scenario purtroppo non è sempre possibile, ecommerce e' un caso ma anche tutti i casi in cui si vuole dare trasparenza (anche se teorica) delle spese di spedizione.

La seconda, che sto sperimentando ma che non mi convince del tutto, e' aggiungere all'ordine un nuovo campo (spedizioni_presenti [nome di tua fantasia]) come campo calcolato (e purtroppo storicizzato altrimenti non puoi fare i filtri) sulle qty da fatturare dei soli prodotti stoccabili. Come accennato tale approccio non mi convince, c'e' l'ho in produzione su un cliente, fa quello che deve fare ma aggiunge una semantica in piu', costringe ad usare filtri custom ma sopratutto aggiunge un campo calcolato non sempre facilissimo da gestire.

Il terzo approccio, quello definitivo, prevede un intervento sul modulo delivery per sanarne il comportamento. La soluzione te l'ha gia' data @davide (servizio fatturabile su milestone) ma la sua gestione a meno è scomoda e non scevra da errori. Nella 13, se non erro o sul master, hanno cambiato qualcosina sul modulo delivery permettendo di scegliere se addebitare le spese "stimate" (ovvero quelle calcolate al momento dell'ordine) o quelle "reali" (risultato del calcolo post spedizione) tale logica potrebbe essere un peletto affinata per rendere consegnato il prodotto servizio di tipo milestone al momento della consegna. Ad oggi vedo quest'ultima strada la piu' pulita e rispettosa di tutte i flussi degli altri moduli/odoo. Purtroppo ci ho pensato tardi e per velocita' so andato sulla seconda ma la lascio come wish del refactory finale del modulo delivery. Una soluzione semplice di questo approccio, senza voler rifare il modulo delivery (non tutti so pazzi come me :D) è di intercettare il metodo di aggiunge delle spese di consegna e modificarne il comportamento da aggiungi a rendi consegnato il prodotto servizio. Certo un po' di codice ti ci vuole ma non tantissimo.

Esclusi questi 3 ne hai altra infinità tutti che possono o meno richiedere qualche intervento sul codice ... dipende da te se accontentarti di quello che c'e' e cercare di trovarne il miglior compromesso oppure intervenire e sanare. Al momento una soluzione con il solo odoo "standard" non esiste.