Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[14.0] l10n_it_fatturapa_in calcolo termini di pagamento e scadenza fattura #2896

Open
francescapenso opened this issue Aug 9, 2022 · 8 comments
Labels
12.0 14.0 16.0 bug no PR yet 🫤 no stale Use this label to prevent the automated stale action from closing this PR/Issue. triaged

Comments

@francescapenso
Copy link

Es 1: importazione di una fattura elettronica il cui fornitore non ha alcun termine di pagamento settata in anagrafica.
L'importazione correttamente tiene conto del termine di pagamento inserito in xml. In questo caso 30 giorni da emissione
https://watch.screencastify.com/v/sx2BfEt749fJ0r1tgzqv

Es: 2 importazione della stessa fattura in cui sul fornitore ho messe come termini di pagamento in anagrafica 60 giorni
L'importazione fa partire i termini di pagamento dalla data in cui importo la fattura e ignora i termini di pagamento dell'xml.
https://watch.screencastify.com/v/TFLDRT2dYq8Zlh85G3k5
In una situazione reale ho anche provato ad importare una fattura elettronica acquisti creata il 5/08/2022 in Odoo, ma importata oggi. Quello che avviene è che la data fattura è quella corretta xml, la data ricezione e-fattura è il 5/08, la data scadenza è 30 giorni da oggi
image

In questo secondo caso secondo me ci sono due errori:

  1. la data da cui partire per i calcoli deve essere quella di emissione della fattura fornitore che si trova in xml e che in ogni caso viene correttamente settata
  2. la data scadenza deve essere quella della fattura xml e non quella settata sul partner. Su questo dettaglio forse si potrebbe ragionare su cosa abbia più senso, se vince xml o la property del partner
    Di fatto cmq prima di salvare lo user può impostare la data che vuole eventualmente volesse tener conto di scadenze\accordi diversi
@TheMule71
Copy link
Contributor

Possibilmente in relazione con #2758

@francescapenso
Copy link
Author

La pr #2759 legata alla issue #2758 l'ho testata e risolve il punto 1 dello scenario 2.

"la data da cui partire per i calcoli deve essere quella di emissione della fattura fornitore che si trova in xml e che in ogni caso viene correttamente settata"

Rimane aperto il punto 2 ovvero se vinca la data impostata da fornitore in xml o i termini di pago generici inseriti nel partner.

@MarcoCalcagni
Copy link
Contributor

Ciao Francesca,

mi dispiace contraddirti ma non sono pienamente d'accordo con "la data da cui partire per i calcoli deve essere quella di emissione della fattura fornitore che si trova in xml e che in ogni caso viene correttamente settata".

per me il giusto ordine di importanza dovrebbe essere:
ordine a fornitore,
partner,
fattura.

nel senso contratto con il fornitore pagamento a 90 giorni, lui (furbo) manda la fattura a 30 giorni, se la importo a 30 giorni non va bene.

su questo se ne è parlato varie volte senza decidere mai nulla. secondo me andrebbe indicato in configurazione quale strada seguire.

@TheMule71
Copy link
Contributor

nel senso contratto con il fornitore pagamento a 90 giorni, lui (furbo) manda la fattura a 30 giorni, se la importo a 30 giorni non va bene.

Ma non hai l'ordine quando importi la fattura.

Quindi il flusso dovrebbe essere: importi la fattura dall'XML con i dati dell'XML (in bozza). Poi, la colleghi ad un ordine di acquisto, e prima di confermarla, il sistema ti avverte di eventuali discrepanze, con l'ordine e/o con le impostazione del partner.

Per fare quello che dici tu, bisognerebbe aggiungere all'ordine la possibilita di importare un XML creando una fattura nel contesto di quell'ordine, allora sì che potresti fare dei controlli in fase di importazione.

Che poi sia action/voce di menu/button e dove appaia poco importa, potrebbe anche essere un wizard quando importi che ti chiede a quale ordine collegare la fattura. Ma senza prima aver specificato un ordine in fase di importazione quel controllo non si riesce a fare, va fatto necessariamente dopo.

@stevech091
Copy link

Io sarei (se non è già casi) di aggiungere nel solito warning anche la discrepanza nel termine di pagamento. Sarà poi l'utente come se a operare di conseguenza su date / termini della fattura.

@TheMule71
Copy link
Contributor

In ogni caso, andrebbe aggiunto qui:
https://github.com/OCA/l10n-italy/tree/14.0/l10n_it_fatturapa_in_purchase

l10n_it_fatturapa_in non credo dipenda da purchase

@francescapenso
Copy link
Author

ciao a tutti, effettivamente non avevo valutato il fornitore furbo o la banale non comunicazione tra uffici vendite/acquisti e le amministrazioni.
A questo punto effettivamente credo che un check tra fattura/ordine (se presente perchè non è detto ne sempre vero) o fattura/partner e poi un warning sia la cosa migliore.
Scegliere una o l'altra strada porta cmq a risultati fuorvianti: da un lato si rischia di mettere una scadenza arbitraria potenzialmente sbagliata del fornitore, dall'altro si rischia di "lisciare" o anticipare un pagamento che potrebbe determinare problemi per l'azienda

Credo che comunque la pr che ho testato risolva il primo problema ovvero partire con i calcoli (qualunque metodo di avviso o di setting si scelga poi) dalla data fattura e non dalla data in cui viene importata su odoo. Questa PR sarebbe mergiable?

Copy link

There hasn't been any activity on this issue in the past 6 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this issue to never become stale, please ask a PSC member to apply the "no stale" label.

@github-actions github-actions bot added the stale PR/Issue without recent activity, it'll be soon closed automatically. label Jun 23, 2024
@TheMule71 TheMule71 added no stale Use this label to prevent the automated stale action from closing this PR/Issue. and removed stale PR/Issue without recent activity, it'll be soon closed automatically. labels Jun 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
12.0 14.0 16.0 bug no PR yet 🫤 no stale Use this label to prevent the automated stale action from closing this PR/Issue. triaged
Projects
None yet
Development

No branches or pull requests

6 participants