# Test parser extras BT (csvBT) - pozitie tert/iban in descriere

## Ce dovedeste testul

`ExtrasBanca_General::csvBT` (`Programe\oproceduri_import.prg:2923`) extrage tert si iban
din campul "Descriere" al CSV-ului BT dupa pozitie fixa (`;`, pozitia 3 = tert, pozitia 4 =
iban). Descrierea nu are acelasi numar de campuri la toate tipurile de tranzactie: la
"Plata OP inter - canal electronic" si "Comision plata OP" apare un camp in plus (numarul
OP-ului) inaintea denumirii, deci pozitia 3 ajunge sa fie numarul OP, iar pozitia 4 (IBAN-ul
real) ajunge sa fie luata drept... denumire, ramanand IBAN-ul real neluat deloc (era pe
pozitia 5, ignorata).

Test pe cele 44 de tranzactii reale ale firmei ROMFAST SRL (5 fisiere `tranzactii_*.csv`,
export BT):

| | inainte | dupa |
|---|---|---|
| Linii cu `iban` care arata a IBAN (`RO`+2 cifre+20 alfanumerice) | 8 | 18 |
| Linii cu `tert` numeric (sigur gresit - e numarul OP-ului) | 10 | 0 |

Cele 10 linii corectate sunt exact tranzactiile "Plata OP inter - canal electronic" si
"Comision plata OP". Celelalte 34 de linii (Incasare OP, Transfer intern, Plata la POS,
Pachet PJ) raman identice inainte/dupa - fix-ul nu le atinge.

## Corectia

`Programe\oproceduri_import.prg`, `Procedure csvBT` (in jurul liniei 3013): in loc de
pozitii fixe 3/4, se cauta in campurile despartite de `;` primul care trece validarea de
IBAN, cu functia deja existenta `VerifIBAN` (`COMUN\programe\oproceduri_comune.prg:7885`,
verifica cifra de control, nu doar forma). Daca se gaseste, `iban` = acel camp, `tert` =
campul dinaintea lui. Daca nu se gaseste niciun camp valid ca IBAN, comportamentul ramane
cel de azi (pozitia 3 = tert, pozitia 4 = iban) - acopera "Transfer intern", "Plata la POS",
"Pachet PJ", unde descrierea nu contine IBAN. Pozitia 2 (numerele de factura,
`lcDescriereFacturi`) nu s-a schimbat.

Capcana gasita si reparata la sursa: `VerifIBAN` (`COMUN\programe\oproceduri_comune.prg:7885`)
nu isi declara variabilele locale si le citeste/scrie neprefixate (`iban`, `mcontrol`, `miban`,
`mibansec`, `rest`, `i`, `dv`). In VFP, un nume nescris fara `m.` se rezolva mai intai la un
CAMP din alias-ul curent, abia apoi la variabila - deci atata timp cat apelantul are selectat
un cursor/tabela cu un camp `iban` (aici `c_iex.iban`, in `csvBT`), citirile si scrierile lui
`VerifIBAN` nimeresc campul, nu parametrul, si functia intoarce mereu `.F.`. Defectul afecta
orice apelant al `VerifIBAN` cu un asemenea cursor selectat - inclusiv formularele din
`onomenclatoare.vcx`/`oparteneri.vcx` care il apeleaza. Fix: `LOCAL mcontrol, miban, mibansec,
rest, i, dv` plus prefix `m.` pe toate referintele la parametru si variabile; logica
neschimbata. Diff: `docs/diff_runda1_verifiban_comun.patch` (fata de
`COMUN\programe\oproceduri_comune.prg.pre_runda1.bak`, alt depozit git decat ROACONT).

`csvBT` nu mai are nevoie de niciun ocol - apeleaza direct `VerifIBAN(m.lcCimp)`.

Diff parser: `docs/diff_runda1_parser_bt.patch` (fata de
`Programe\oproceduri_import.prg.pre_runda1.bak`).

## Cum se ruleaza testul

`teste_extras_bt.prg` (radacina proiectului) instantiaza clasa reala `ExtrasBanca_General`
si ruleaza `csvBT` peste toate fisierele `tranzactii_*.csv` dintr-un folder dat ca parametru,
fara Oracle (doar `SET PROCEDURE` pe `oproceduri_import.prg`, `COMUN\programe\oproceduri_comune.prg`,
`COMUN\programe\regex.prg`). Scrie rezultatul in `<folder>\rezultat_test_bt.txt`.

```powershell
$folder = 'D:\calea\catre\fisierele\tranzactii_bt'
$p = Start-Process 'C:\Program Files (x86)\Microsoft Visual FoxPro 9\vfp9.exe' -ArgumentList '-A','-T',"`"D:\roa\ROACONT\teste_extras_bt.prg`" $folder" -PassThru
$p.WaitForExit(120000)
```

Fisierele CSV reale folosite la test (denumiri parteneri + IBAN-uri reale ROMFAST SRL) NU
sunt in `docs/` - raman in scratchpad-ul sesiunii, nu s-au comis.

## Neacoperit

- **Fara IBAN in descriere** (26 din 44 de linii: "Transfer intern", "Plata la POS",
  "Pachet PJ"): partenerul nu se poate deduce din descriere in aceste cazuri, fix-ul nu are
  ce corecta - comportament identic cu inainte.
- **IBAN strain**: `VerifIBAN` cere exact 24 de caractere (lungimea IBAN romanesc), deci un
  IBAN strain (alta lungime) nu e recunoscut si linia cade pe comportamentul de azi
  (pozitiile fixe 3/4) - degradare sigura, nu regresie, nu era acoperit nici inainte.
- Nu s-a testat `tnTip = 2` (extras de cont final de luna, alt layout de coloane CSV) -
  fisierele disponibile au fost toate `tnTip = 1` (lista de tranzactii).