add: bulk merge of partners duplicated on the same VAT

[dhongu]

Adds deltatech_partner_merge: merging partners duplicated on the same VAT number, from the
interface, in bulk.

De ce

Mecanismul standard nu e utilizabil, și nu doar la volum. Măsurat pe o copie a bazei unui client
(543.036 parteneri, 1.163.295 note contabile), cu indexurile deja create:

Operațiune	Timp
Unificarea a două fișe, wizardul standard	0,81 s · 1,96 s · 13,34 s · 21,01 s · 0,97 s — medie 7,62 s
Campania întreagă (4.235 de grupuri) la ritmul ăsta	9 ore
Aceeași campanie, prin acest modul	circa 5 minute

Cauza: standardul parcurge toate cele ~158 de coloane care referă res_partner pentru fiecare
pereche. Modulul inversează buclele — o instrucțiune per coloană, pentru tot lotul.

Separat, pe aceeași bază lipseau 67 de indexuri pe coloanele FK către parteneri. Ștergerea unei
fișe: 499 ms fără ele, 27 ms cu ele (crearea tuturor a durat o secundă). Modulul semnalează
situația și oferă butonul de creare.

Cum

Reia interogările din scripts/partner_merge/*.sql, strânse în models/sql_queries.py. Singura
diferență față de scripturi e stratul de meta-comenzi psql (\gexec, \if, variabilele -v), care
devine parametri și Python. Tabelele de lucru păstrează numele, deci un lot pregătit din interfață
poate fi inspectat din psql.

Cheile străine rămân active pe tot parcursul: integritatea e garantată de PostgreSQL, nu de
corectitudinea procedurii, și nu e nevoie de superuser — deci merge și pe odoo.sh.

Patru pași: Analizează → Simulează → Aplică → Verifică, cu bară de stare care nu permite
aplicarea înainte de simulare.

Simularea rulează într-un savepoint și îl anulează, deci nu poate scrie nici dacă acest cod ar
greși. Deliberat nu pe un al doilea cursor: tabelele de lucru se creează în tranzacția curentă, iar
CREATE TABLE ține lock ACCESS EXCLUSIVE până la commit — un al doilea cursor se blochează
așteptând un commit care vine abia după ce simularea se întoarce. Am pierdut zece minute pe deadlock-ul
ăsta la prima variantă; explicația e în cod, ca să nu fie „reparat" înapoi.

Aplicarea refuză să se încheie dacă rămâne vreo referință către o fișă absorbită.

Gărzi și clasificare

Categorie	Situație	Tratament
A	o fișă are documentele, restul sunt goale	automat
B	documente pe o singură fișă	automat
C	facturi pe mai multe fișe	manual, cu contabilitatea
D	sold nereconciliat pe mai multe fișe	manual, după închiderea lunii

Excluse automat din lot: grupurile care conțin fișa companiei proprii, cele cu utilizatori de portal
pe mai multe fișe, și cele cu denumiri complet diferite pe același CUI.

Fișa păstrată se alege după volumul de documente — ceea ce nu e același lucru cu calitatea denumirii.
De aceea masterii cu nume care pare lipit la import sunt marcați, cu denumirile absorbite alături,
capturate înainte de merge (după, ele nu mai există).

Verificat

Pe copia de producție, din interfață:

	Rezultat
Clasificarea	identică cu cifrele procedurii SQL, până la ultimul grup
După simulare	toate cele 30 de fișe ale lotului existau încă
După aplicare	30 absorbite, 30 de masteri păstrați
Verificare	0 abateri pe facturi, comenzi și sold; 0 fișe rămase
Denumiri degradate	3 semnalate, cu varianta corectă

Anterior, procedura SQL echivalentă a fost rulată pe staging-ul clientului: 575 de fișe în trei
loturi, zero abateri.

Note

• depends doar pe base: sub-interogările pe account_move, sale_order, purchase_order,
  stock_picking sunt protejate cu to_regclass.
• CREATE INDEX CONCURRENTLY nu poate rula în tranzacția Odoo, deci butonul creează indexurile
  normal (lock de secunde pe tabelele mari); formularul trimite explicit la 01_fk_indexes.sql pentru
  instanțele unde nici atât nu e acceptabil.
• Purjarea contactelor orfane rămâne script — e o ștergere în masă care merită să fie deliberată.
• Două grupuri de acces separate: a pregăti și a simula ≠ a aplica.