openobject-italia-core-devs team mailing list archive

[Davide Corio <davide.corio@xxxxxxxxxxxx>]

Il giorno mer, 15/09/2010 alle 20.28 +0200, Giuseppe D'Alò C.& G.
Software S.a.s. ha scritto:
> Le numerazioni dei documenti iva italiani   sono molto più complesse
> della semplice relazione progressiva numero data. In effetti queste
> numerazioni dipendono anche dal sezionale (che può essere alfa
> numerico) e dal registro iva. Quindi quando emetto un documento devo
> controllare che la data del documento non sia inferiore a quella
> dell'ultimo documento dello stesso sezionale es: la fattura 13/A del
> 15/01/2010 e la 13/C del 10/01/2010 sono regolari tra loro, la 14/A
> dovrà avere data superiore o uguale al 15/01 e la 14/C  dovrà avere
> data superiore o uguale al 10/01. Entrambe le numerazioni possono
> andare sullo stesso registro iva e l'ordinamento sarà per data
> registrazione,data documento,sezionale,numero documento . Posso
> ovviamente avere più registri iva vendite.

Ciao Giuseppe,
le tue delucidazioni sono sicuramente molto apprezzate!!

Per le numerazioni, stavamo appunto pensando di creare degli oggetti
contatore "intelligenti", maggiormente configurabili con i quali poter
colmare in una volta sola tutte le eventuali mancanze.


> Per i DDT e le BOLLE DI ACCOMPAGNAMENTO(per i regimi fiscali ancora
> sottoposti a questo documento) le regole dei progressivi sono proprio
> le stesse, con le bolle che hanno la caratteristica di non poter
> essere ristampate ed annullate.

Uh, questa mi suona nuova.
Quindi agli utenti che cercano di annullare una bolla su openerp e si
lamentano perchè non ci riescono possiamo dire che è la legge che lo
prevede? :)

> Nella fase di creazione del documento quindi necessita prima conoscere
> il sezionale in modo da poter gestire e controllare  il progressivo e
> verificare l'ultima data documento.

Per sezionale intendi il registro iva?

> Per i documenti di carico ho solo un progressivo da gestire sul
> registro iva detto numero di protocollo, sul registro acquisti saranno
> ordinati per data registrazione e numero di protocollo ovviamente
> senza buchi e salti.

Ho controllato la localizzazione proposta da servabit dove dicono di
aver introdotto la gestione dei registri iva.
Purtroppo ho paura che non sia recuperabile, quindi ci tocca fare degli
oggetti "from scratch", però da quanto ho studiato, non sembra nulla di
complesso dal punto di vista tecnico.

> La fattura proforma è un documento che nulla ha di fiscale
> (tecnicamente ci basta una stampa) che posso generare da DDT o da un
> ordine cliente con un suo progressivo, quindi non legato a quelle
> regole di cui sopra e che prima o poi dovrà generare una fattura che
> avrà il progressivo e la data del giorno in cui viene emesso e nel
> corpo fa riferimento oltre che al DDT di consegna anche alla fattura
> proforma

Tu intendi quindi il documento valido a fini doganali e così via giusto?

C'è anche la pro-forma dei liberi professionisti (avvocati, notai, etc
etc) che però crea movimenti contabili particolari (per via di ritenute,
cassa previdenza, etc etc) che è quindi da studiare con calma.

> Anche se non ha tutti i torti OpenErp è troppo rigido sulla
> modificabilità dei documenti. L' ideale sarebbe che un ordine è
> modificabile fino a che non si è emesso un DDT o una FATTURA
> ACCOMPAGNATORIA (controllo da effettuare a livello di riga ordine), un
> DDT è modificabile sino a che non si è generata una fattura, una
> fattura è modificabile sino a che non si decide di contabilizzarla. In
> un paio di Erp italiani che conosco mi basta cancellare la
> registrazione in prima nota della fattura per modificarla e così via
> sino a tornare all'ordine. Questa cosa la vedo complessa in OpenErp
> visto che abbiamo solo la classe sale e i documenti DDT e FATTURA sono
> solo proprietà della classe sale.

In realtà, anche in openerp basta annullare eventuali movimenti
correlati per poter annullare un documento.
L'unico problema è che spesso il workflow crea automaticamente troppi
movimenti in giro per il sistema e quindi annullare qualcosa spesso è
incasinato.
Ma si tratta di semplificare il wf e rendere più manuali alcune
procedure.


> Normalmente il tipo conto del piano dei conti è usato dagli
> sviluppatori per mettere in piedi automatismi e calcoli . ù

Si, anche qui, c'è il "tipo interno" che ha questa funzione

> Per ciò che riguarda la codifica del piano dei conti il problema si
> pone in termini di ordinamento in caso di chiave alfanumerica 1,12,2
> anzichè 01,02,12 questa cosa è importante nel caso di stampa di
> bilancio a partite contrapposte.

Cosa sarebbe un bilancio a partite contrapposte? :(

> Spero di non averVi annoiato ed  attendo Vostre valutazioni

Ci mancherebbe, ce ne servono di più!!


-- 
Davide Corio
email: davide.corio<at>domsense.com
web: http://www.domsense.com