Italian Problema correttezza movimento contabile

[amorosik]

Mi sono imbattuto in un problema un po' strano
Schermata Movimenti Contabili, e' possibile inserire un Totale Movimento, poi una sequenza di righe che movimentano l'Iva, ed alla fine le righe contabili
Una cosa del genere:
TOTALE MOVIMENTO: 226,00 (in Avere)
1 RIGA IVA: 22%, 100,00 euro, iva 22,00 euro (in Avere)
2 RIGA IVA: 4%, 100,00 euro, iva 4,00 euro (in Avere)
1 RIGA CONTABILE: CLIENTE PEPPE SRL, 226,00 euro (in Dare)
2 RIGA CONTABILE: RICAVI VENDITE FERRAMENTA, 200,00 euro (in Avere)

Un ragioniere tradurrebbe cosi:

DARE AVERE
-------- ---------
. . . . . . 22,00 (Iva per prodotti al 22%)
. . . . . . 4,00 (Iva per prodotti al 4%)
226,00 . . . . . (valorizza conto Clienti, cod cli=xyz)
. . . . . 200,00 (valorizza conto Ricavi..)

Bene, fin qua' tutto normale
Chiama un utente di questo programma, "...eeeehhh ma programma sbaglia i conti, i valori sul Bilancio del mese non corrispondono al registro Iva dello stesso mese...."
Bon vediamo
Dai primi controlli non salta fuori niente, tutti i movimenti sono perfettamente in quadratura
Il problema lamentato e' che il totale Imponibile sui Registri Iva risulta diverso dal valore Imponibile che appare sul Bilancio periodico, in sostanza quel 200,00 euro e' limponibile del movimento che contribuisce a valorizzare i dati nel Bilancio periodico, e dovrebbe corrispondere all'imponibile che appare nei Registri Iva che riportano l'imposta dei 22,00 euro + 4,00 euro
Alla fine della fiera scopro che il movimento era fatto cosi:

DARE AVERE
-------- ---------
. . . . . . 12,00 (Iva per prodotti al 22%)
. . . . . . 4,00 (Iva per prodotti al 4%)
226,00 . . . . .(valorizza conto Clienti, cod cli=xyz)
. . . . . 210,00 (valorizza conto Ricavi..)

In buona sostanza la quadratura tra Dare ed Avere del movimento e' corretta
Ma mentre nel Bilancio periodico alla voce (Ricavi Vendite Ferramenta) viene inviato quel 210,00 euro, ai regisri Iva viene inviato un 12 euro di imposta per prodotti al 22% ed un 4 euro di imposta per prodotti al 4%, e quindi l'imponibile che appare sul Registro Iva e' inferiore ai 210,00 che appare nel Bilancio

Bene, per i valorosi che hanno avuto la pazienza di seguire fin qua, ora viene la domanda: come realizzare una procedura che scovi questo tipo di errori?
Attansion, potrebbero esserci altre righe ad esempio un 10 euro sia in Dare che in Avere, che movimentano altri conti tipo spese o roba del genere

 

[Elric]

Non vedendo l'algoritmo si fa un po' fatica.

Dai miei blandi ricordi di uno studio molto rudimentale (non sono né un ragioniere né un commercialista men che meno un economista), dovresti tenere separati i mastrini della merce da quelli iva, da quelli cassa, banca, crediti, debiti etc.

Il dare/avere sono manifestazioni dell'aspetto economico e di quello finanziario, che ricadono nel dare e avere a seconda della connotazione attiva o passiva di questi due aspetti.

Se salti qualche passaggio o semplifichi l'uso dei mastrini, magari accorpandoli, o sei molto molto molto bravo in contabilità o facilmente rischi l'errore di programmazione.

Se hai impostato male l'algoritmo, creare un algoritmo di controllo rischi di finire dentro un circolo vizioso, un costante rincorrere l'errore che porta ad altri errori.

È la stessa partita doppia che, com'è formulata, ha dentro di sé il controllo e ti fa evitare l'errore.

 

[amorosik]

Ringrazio per la risposta
Ma la partita doppia ti evita solamente di mettere dentro movimenti non in quadratura tra il dare e l'avere
Se hai una vendita per 122 euro di prodotti al 22%, e da una parte (supponiamo in Dare) metti il 122 euro sul conto cliente, dall'altra parte (supponiamo in Avere) metti 120 euro sul conto Vendite Ferramenta, e 2 euro sul conto Iva a debito, il movimento e' in perfetta quadratura
Pur essendo sostanzialmente sbagliato (dovrebbe essere 100 euro sul conto Vendite Ferramenta, e 22 euro sul conto Iva a debito)

Il consiglio che stavo cercando e' come evitare di inserire movimenti sbagliati di quel tipo
Tenendo presente che potrebbero esistere anche altre righe oltre alle tre indicate sopra, e quindi NON e' sufficiente prendere le righe iva, nell'esempio sopra i 2 euro (da Iva al 22%), calcolare l'imponibile (che verrebbe 9,09 euro), e verificare che la somma tra imposta ed imponibile (in questo caso 11,09 euro) sia uguale alla somma degli importi dall'altro lato (in questo caso 122 euro)
Scrivo che non e' sufficiente questa verifica perche' potrebbe esistere una quarta riga in Dare che valorizza un certo conto per 1 euro (e quindi totale Dare 122+1=123 euro) ed un quinta riga in Avere che valorizza altro conto per 111,91 euro (totale Avere = 9,09 + 2,00 + 111,91=123 euro), la verifica passerebbe pur col movimento completamente scorretto

 

[Elric]

Non ho capito bene il tutto e resta sempre difficile senza avere algoritmo o interfaccia.

Ad esempio, non ho capito se l'utente immette solo il lordo, solo l'imponibile, imponibile e iva, imponibile e poi sceglie da un elenco l'iva, lavori a monte con dei codici a barre o altro...

Se per singola riga hai da scegliere solo che percentuale iva applicare... i casi sono 2: o sbaglia l'utente o sbaglia l'algoritmo nel calcolo e nell'applicazione dei principi contabili.

Se su 122 lordo l'algoritmo calcola un valore diverso da 22 con un'iva al 22% è sbagliato l'algoritmo.

Se invece è un valore che viene messo a mano ha sbagliato l'utente.

Poi, questo:

 

[Elric]

DARE AVERE
-------- ---------
. . . . . . 22,00 (Iva per prodotti al 22%)
. . . . . . 4,00 (Iva per prodotti al 4%)
226,00 . . . . . (valorizza conto Clienti, cod cli=xyz)
. . . . . 200,00 (valorizza conto Ricavi..)

E questo

DARE AVERE
-------- ---------
. . . . . . 12,00 (Iva per prodotti al 22%)
. . . . . . 4,00 (Iva per prodotti al 4%)
226,00 . . . . .(valorizza conto Clienti, cod cli=xyz)
. . . . . 210,00 (valorizza conto Ricavi..)

Assomiglia più a un libro giornale. 12 di iva al 22% è un lordo di 66,55 con una base imponibile di 55,54.

 

[amorosik]

L'operatore indica sulla testata del movimento il 'totale movimento', supponiamo 226,00

Poi il focus passa sulle righe Iva, dove l'operatore indica il 'codice Iva', il programma in risposta visualizza l'aliquota di quel codice iva, e propone una coppia imponibile/imposta tale da completare piu' possibile il 'totale movimento', quindi se il codice iva scelto e' il 4 il programma proporra' il 4% come aliquota, 217,31 come imponibile e 8,70 come imposta
A questo punto l'operatore indichera' sul campo imponibile il valore corretto degli articoli al 4%, che e' di 100 euro, ed il programma rispondera' ricalcolando l'imposta del 4% sui 100 euro appena inseriti, e quindi 4 euro di Iva
Dopo l'inserimento delle prima riga iva, il programma 'sentendo' che il 'totale movimento' non e' stato ancora esaurito da imposta+Iva della riga inserita, rimarra' nella fase inserimento righe Iva

L'operatore indichera' il codice Iva da usare, ad esempio 22, il programma rispondera' visualizzando l'aliquota di quel codice Iva e proponendo un imponibile+Iva tale da completare piu' possibile il 'totale movimento' tenendo conto delle righe Iva gia' inserite, in questo caso proporra' 22% come aliquota, 100 euro come imponibile, 22 euro come imposta, l'operatore vedendo che l'imoponibile proposto e' di 100 euro e quindi il valore degli articoli al 22% confermera' la seconda riga Iva

A questo punto il programma vedendo che la somma imposta/iva delle due righe esaurisce completamente il 'totale movimento' passera' il focus nella zona delle righe contabili, proponendo sia la riga che movimenta il conto del cliente (pari a 226,00 euro) , sia la riga che movimenta il conto Ricavi Vendite ALimentari (pari a 200 euro)

Questa descritta sopra e' la normalita', ma la mia richiesta e' come scovare errori subdoli del tipo descritti all'inizio
Ad esempio se l'operatore durante l'inserimento della prima riga Iva, al posto di scrivere 100,00 euro come imponibile per articoli al 4% scrivesse 10,00 euro, il programma proporrebbe l'iva pari al 4% di 10 euro, e durante le righe successive tenterebbe di 'completare' il consumo di imponibile+iva pari al 'totale movimento'
E quindi si, stiamo parlando di un errore dell'operatore, ma che deve essere intercettato dal programma nel momento che l'operatore tentasse di memorizzare il movimento scorretto

 

[LucaMs]

Ad esempio se l'operatore durante l'inserimento della prima riga Iva, al posto di scrivere 100,00 euro come imponibile per articoli al 4% scrivesse 10,00 euro, il programma proporrebbe l'iva pari al 4% di 10 euro, e durante le righe successive tenterebbe di 'completare' il consumo di imponibile+iva pari al 'totale movimento'
E quindi si, stiamo parlando di un errore dell'operatore, ma che deve essere intercettato dal programma nel momento che l'operatore tentasse di memorizzare il movimento scorretto

Ma se l'operatore sbaglia l'immissione di una riga, il totale (i vari totali) non corrisponderanno al totale movimento immesso per primo, quindi dov'è il problema? A quel punto il sw dovrebbe impedire di registrare il movimento o perlomeno avvertire e consentire la forzatura.

 

[Elric]

Ok, ho capito. Forse.

Hai un ordine, con più righe d'ordine, con voci alte quali si applica l'iva al 4% e voci alle quali si applica l'iva al 22%.

Man mano che l'operatore inserisce i valori delle singole righe d'ordine, il programma tenta di prevedere e suggerire all'operatore gli importi da inserire per le righe successive.

Ora, a parte quanto già scritto da LucaMs, l'unico modo che vedo io, visto che 10 è sbagliato ma potrebbe ben essere un valore corretto, è far fare al programma tutte le possibili combinazioni.

All'inserimento, dovrebbe verificare se il valore rientra in uno di quelli delle combinazioni calcolate e ridurre le combinazioni possibili da verificare al momento dell'inserimento.

Se così è, altro non mi viene in mente e mi pare anche una bella sfida! In bocca al lupo!

 

[amorosik]

Ma se l'operatore sbaglia l'immissione di una riga, il totale (i vari totali) non corrisponderanno al totale movimento immesso per primo, quindi dov'è il problema? A quel punto il sw dovrebbe impedire di registrare il movimento o perlomeno avvertire e consentire la forzatura.

Si, tutto sta a definire con precisione cosa voglia dire "operatore sbaglia"
Perche' dal "totale movimento" non si puo' capire a priori se ci siano righe Iva oppure no
Ed anche se ci sono non e' possibile capire quali siano
E' l'operatore che indica il Codice Iva della riga che sta inserendo, ed accetta i valori proposti, oppure li modifica magari perche' ci sono piu' aliquote diverse e quindi l'imponibile/imposta che il programma propone non e' la coppia corretta
Sicuramente il controllo correttezza e' possibile farlo, non ho ancora ben individuato come farlo