ARGOMENTO: DDT & C.

Piccolo sondaggio.

Porto franco, porto assegnato e gli altri tipi di trasporto, voi dove li mettereste.

Gli Incoterms, ovvero l'equivalente di questi valori, ma inerenti l'export della merce, sono nella scheda "altri dati" dell'ordine di vendita.

Quindi a rigor di logica dovrebbero stare li.

Inoltre, essendo una select, come chiamereste il campo
Il termine corretto, secondo wikipedia dovrebbe essere "trasporto", ma è anche molto ambiguo.

risolto, i corrieri lo definiscono come tipo di "pagamento", giustamente

Ciao a tutti.

Mi chiamo Alessio e sono nuovo del mondo openERP.

Lavoro da oltre 15 anni in ambito gestionale occupandomi principalmente dell'analisi e lo sviluppo di moduli nella nostra piattaforma gestionale.
Un ERP completo per la piccola/media azienda italiana.

Sto valutando il prodotto, e devo dire che lo trovo estremamente potente e flessibile ma d'altro canto noto che c'è molto lavoro da fare.

Rispondendo alla tua domanda, di solito quell'informazioni è definita "PAGAMENTO SPEDIZIONE", come hai aggiunto correttamente te.

Diciamo che per l'azienda che emette il DDT è necessario indicare:

1) Un codice di trasporto (Gomma,Nave,Aereo); di solito abbinato al trasporto abbiamo anche l'indicazione del responsabile, del soggetto che materialmente si occuperà della spedizione (Mittente,Destinatario,Vettore)

2) Una condizione di pagamento, che sta ad indicare chi pagherà il trasporto (porto franco = paga il mittente, porto assegnato = paga il destinatario ecc.)

3) Una causale del trasporto (Vendita, c/lavoro, c/vendita, c/comodato, ecc. ecc.)

4) L'aspetto dei beni (pallet, cartoni, scatole, ecc.)

5) Se il trasporto è a cura del/dei vettore/i (infatti possono anche essere più di uno) è necessario indicare sul DDT i dati anagrafici degli stessi.

6) La data e l'ora inizio trasporto (poi ci deve essere lo spazio sulla copia del ddt per permettere al secondo vettore di indicare la data/ora del suo ritiro e del suo inizio trasporto....nei casi in cui ritiri la sera e riparta la mattina seguente)

7) Il numero dei colli, il peso netto e il peso lordo (questi pesi sono calcolati solitamente in automatico dai pesi dei prodotti, ma deve essere liberamente modificabile)

8) I campi Spese con i relativi importi/percentuali e i codici iva (trasporto,imballo)

9) Annotazioni del trasporto (campo note facoltativo)


Ciao

Alessio

alessiog ha scritto:
Benvenuto!

Un gestionale o un ERP?
L'ho detto più per ironia che per altro.
Stiamo cercando di far comprendere la differenza tra un software gestionale e una piattaforma ERP, così che la gente non prenda abbagli durante la scelta del software.
OpenERP non è di certo adatto alle piccole realtà che cercano un software di fatturazione, siccome la gestione delle attività in OpenERP richiede parecchie conoscenze ed impegno.

Eh si...senza alcun dubbio.
Nell'ultimo mese la community si è data comunque molto da fare ed abbiamo già ora un prodotto usabile in italia con in moduli sparsi che abbiamo confezionato.
Penso che nel giro di un mese da oggi avremo qualcosa di livello sicuramente superiore.

Ottimo, ne abbiamo appena discusso su IRC e seguendo in rete la storia del termine "porto franco" si è arrivati a capire che è un termine che deriva ancora dal commercio marittimo, e "porto" è inteso proprio come "porto marittimo"...curioso...ma sappiamo tutti che l'italia è fatta di usanze più che di regole

Ok, ci siamo quasi.
In realtà c'è tutto, l'importante è averlo a portata di mano

Ciao enlightx.

15 anni fa, quando sono entrato a lavorare si parlava solo di gestionale.
Noi ne avevamo uno scritto internamente con un RAD israeliano molto potente.
Tieni presente che abbiamo fatto il salto dal DOS a Windows senza riscrivere niente.

Dopo 10 anni il prodotto iniziava ad essere da reingegnerizzare...viste le numerose "pezze" aggiunte in momenti successivi, e alle personalizzazioni dei clienti più importanti che facevano da padroni anche sulle scelte funzionali del prodotto.

5 anni fa quindi abbiamo iniziato lo sviluppo prima del RAD interno, un sistema di sviluppo visuale, che sfruttando il linguaggio PHP, producesse dinamicamente statement sql e interfacce, poi del nuovo sistema gestionale, che avesse avuto le caratteristiche di un moderno ERP.
Ovviamente il focus si è spostato verso la media impresa, e i piccoli sono rimasti con il "vecchio" ma "glorioso" gestionale.

Diciamo che anche noi abbiamo un OpenObject e un OpenERP.
Difficilmente scriviamo codice, perché anche la parte esecutiva (server-side) è totalmente comandata da istruzioni interne, e laddove il sistema non preveda una determinata situazione, siamo in grado di uscire allo scoperto scrivendo codice php.
Il modulo di runtime può produrre doppia interfaccia (web e gtk).
Ancora non ho avuto modo di vedere OpenObject da vicino, in tal senso per cui non sono in grado di fare un paragone, ma da quello che ho letto posso dire che sposo in pieno la filosofia di base.

Prima di valutare openERP ho visto anche altri prodotti: Compiere e i suoi derivati.
Sono decisamente più avanti in termini di funzionalità rispetto a openERP, ma è molto complesso lavorarci sopra. Per poter essere competitivi lo strumento deve permetterti di implementare rapidamente, altrimenti sei tagliato fuori.

Ho letto che ti stai occupando di un nuovo sistema per la reportistica, ma a che punto sei?
Il sistema attuale è quasi inutilizzabile.
Se hai bisogno di un beta tester....

A presto.

Alessio

Quello usato inizialmente da SAP B.O.?

Vedo che hai compreso esattamente il motivo per cui siamo qui

Io mi sono sempre occupato di progettazione intranet e gestione documentale. Al mondo ERP ci sono arrivato per cause di forza maggiore, siccome le integrazioni con il mondo proprietario non sono mai agevoli. Così ho deciso di fare, qualche anno fa, una cernita dei vari progetti open.

Ho guardato Compiere, OpenBravo, Adempiere, Oratio e simili, ma con OpenObject abbiamo trovato il terreno ideale.
Python è decisamente più produttivo di altri linguaggi anche messo in mano a sviluppatori junior e così siamo in grado di fornire personalizzazioni in tempi rapidissimi.

E' pronto!
Volevamo fare il rilascio ieri, ma alla fine abbiamo preferito dare urgenza al modulo comprensivo di delle localizzazioni già sviluppate.
Non penso tarderemo a rilasciarlo, spero già lunedì a questo punto.

I prossimi passi in vista del 12 saranno supporto standard CBI e strutturazione dei registri IVA che così come sono "nascosti" in OpenERP non vanno bene per le attività che si tengono la contabilità in casa.
Si tratta comunque di poca attività.

Felicissimi di avere qualche esperto del settore nella community