:+1

Penso che la soluzione che proponete per gestire i casi sporchi comunque non introduca problemi nei casi puliti.

Vale a dire:

1.  cerco fra i fornitori, se trovo il partner recupero il commercial_partner e lo uso
   
2.  se non lo trovo, cerco fra tutti i partner; se lo trovo, recupero il commercial_partner e lo uso
   
3.  se non lo trovo, lo creo

Non so se, nel caso trovassi qualcosa al punto 2, imposterei automaticamente a fornitore. Magari ho anche una gerarchia sporca.

Piuttosto al punto 2 aggiungerei: se lo trovo, registro che il partner non è un fornitore con self.log_inconsistency

Così envetualmente l'utente può andare a far pulizia.

On Thu, 7 Feb 2019 at 14:57, Lara Baggio <lbaggio@linkgroup.it> wrote:

Il giorno gio 7 feb 2019 alle ore 14:41 Lorenzo Battistini <elbaddy@gmail.com> ha scritto:

Non so, non sarebbe meglio se il partner fosse unico? Perchè volerne 2?

Ovviamente in caso di nuove istanze, o quando creano nuovi partner glieli facciamo creare singoli con entrambi i flag, dove necessario.

Abbiamo però alcuni caso, con dati che arrivano da precedenti gestionali o da vecchie istanze che non hanno voluto mantenere la separazione.

Non potendo proporre un partner unico, l'importazione non va avanti.

Qualche altra proposta?

Per noi dobbiamo per forza creare un PR che gestisce tale casistica. La teniamo per noi? :D

  Lara Baggio | Analysis and Development

Link IT Srl - Servizi integrati avanzati

via Trieste, 47 - 21020 Buguggiate (VA)

http://www.linkgroup.it | tel +39.0332456511

 

L'erp open source per la tua azienda senza costi di licenza!

Scopri la nostra offerta cloud all'indirizzo erp-pmi.it

 

On Thu, 7 Feb 2019 at 12:22, Matteo Bilotta <byloth@gmail.com> wrote:

Ciao!

Occhio a non creare duplicati!

Iniziamo il ragionamento, prendendo in considerazione l'eventualità che non tutti abbiano anagrafato, correttamente, i propri partner; un partner che dovrebbe essere "Fornitore" potrebbe, benissimo, risultare a sistema come un "Cliente" oppure senza una classificazione precisa (chi ha anagrafato il cliente si è dimenticato di "flaggare" sia la checkbox "Cliente" che quella "Fornitore").

Per evitarci brutte sorprese e la creazione di eventuali duplicati, teniamo in considerazione anche questi casi sopracitati.

Una possibile soluzione potrebbe essere l'aggiunta di un flag all'interno delle configurazioni che consenta di scegliere la modalità di gestione dell'importazione, cosicché si abbia coscienza dell'effettivo comportamento e non si rischi di avere brutte sorprese.

Nella mia mente, mi immagino un flag sotto la sezione "Fatturazione elettronica" delle configurazioni, tipo: 'Esegui la distinzione tra partner "Cliente" e partner "Fornitore" in fase di importazione' oppure 'Mantieni divisi i partner "Cliente" dai partner "Fornitori"'. Lo setterei disabilitato di default.

---

MA, partendo dal presupposto sia necessario disincentivare la creazione di anagrafiche doppie...

La soluzione ottimale, quindi, potrebbe essere quella di partire a ricercare i partner, inizialmente, filtrando gli stessi solo per "Fornitori".

Qui, poi, verrebbe eseguito il controllo di integrità solo sui partner "Fornitori" (in cerca di eventuali partner doppi).

Qualora, invece, non fosse possibile trovare il partner interessato tra i fornitori, prima di lanciarne la creazione, si potrebbe eseguire una nuova ricerca senza filtri (su tutti i partner presenti a sistema).

A questo punto verrebbero eseguiti, nuovamente, i controlli d'integrità di cui sopra e solo se quest'ultima ricerca risultasse infruttuosa, si andrebbe a creare il partner in anagrafica.

Piccola nota a margine...

Nel caso in cui, il partner, venisse identificato tra tutti gli altri partner (quindi senza flag "Fornitore") potrebbe essere una cosa buona e giusta, andare a valorizzare in maniera automatica tale flag, rendendolo a tutti gli effetti, un fornitore correttamente anagrafato (rendendo, oltretutto, più veloci tutte le successive importazioni di fatture a lui collegate).

--- 

Occhio a gestire correttamente anche tutti i casi di partner "Padre" / "Figlio"...

Buon lavoro.

Il giorno gio 7 feb 2019 alle ore 10:01 Lara Baggio <lbaggio@linkgroup.it> ha scritto:

Buongiorno a tutti, 

abbiamo avuto un problema con un nostro cliente e vorrei sottoporvelo, e se siete d'accordo aprire un PR.

Iin fase di importazione della fattura_in esiste questo controllo

for partner in partners:
    if (
        commercial_partner_id and
        partner.commercial_partner_id.id != commercial_partner_id
    ):
        raise UserError(
            _("Two distinct partners with "
              "VAT number %s or Fiscal Code %s already "
              "present in db." %
              (vat, cf))
            )
    commercial_partner_id = partner.commercial_partner_id.id

dove partners è il risultato della ricerca su tutti i partner con partita iva
o codice fiscale presente nell'xml

Alcuni nostri cliente, per motivi storici, hanno due partner con la medesima partita iva, uno  come customer e uno come supplier.

Non potendo costringerlo a farlo diventare un solo partner che sia supplier e customer, 

vorrei introdurre un parte che ragiona anche sul tipo di partner.

Essendo una fattura di acquisto, per prima cosa farei esattamente quello che viene fatto ora, ma solo sui partner di tipo supplier.

Se non ne trova, allora fa il medesimo controllo sui customers. 

A questo punto se i dati sono coerenti aggiunge al customer anche il flag supplier e ritorna il commercial_partner_id.

Che ne dite? 

Avete altri suggerimenti?

Grazie, 

Lara

  Lara Baggio | Analysis and Development

Link IT Srl - Servizi integrati avanzati

via Trieste, 47 - 21020 Buguggiate (VA)

http://www.linkgroup.it | tel +39.0332456511

 

L'erp open source per la tua azienda senza costi di licenza!

Scopri la nostra offerta cloud all'indirizzo erp-pmi.it

_______________________________________________
Mailing-List: https://odoo-community.org/groups/italy-53
Post to: mailto:italy@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

--

Matteo Bilotta (Byloth)

Software Architect

Sito web: https://www.byloth.net/

You can also find me on...

_______________________________________________
Mailing-List: https://odoo-community.org/groups/italy-53
Post to: mailto:italy@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

--

Lorenzo Battistini
https://github.com/eLBati

_______________________________________________
Mailing-List: https://odoo-community.org/groups/italy-53
Post to: mailto:italy@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: https://odoo-community.org/groups/italy-53
Post to: mailto:italy@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

--

Lorenzo Battistini
https://github.com/eLBati

_______________________________________________
Mailing-List: https://odoo-community.org/groups/italy-53
Post to: mailto:italy@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

Antonio M. Vigliotti

Presidente eletto associazione Odoo Italia

Mobile (+39) 342.8740910

4 attachments 4 attachments