# S4b etapa 1 - contractul ConstruiestePropunereSincronizare/AplicaSincronizareArticole

Implementare, nu doar proiectare. Cod nou exclusiv in `COMUN\programe\ofacturare_editare.prg` (dupa
`ScrieArticoleFacturaEditate`). Niciun `.vc2` atins - formularul si dialogul raman etapa 2, a altui
agent. Baza: `docs\propunere_s4b_sincronizare.md` (proiectarea aprobata, punctele 2 si 4) si
`docs\cercetare\rec_suma_act.md` E.3 (formula de agregare RUL, reutilizata neschimbata).

## Functii noi (publice, apelabile din etapa 2)

### `ConstruiestePropunereSincronizare(tcDirectie)`

Parametru: `tcDirectie` - accepta exact doua valori, `'RUL_SURSA'` (rulajul e sursa, actualizeaza
articolele facturii) sau `'ARTICOLE_SURSA'` (articolele sunt sursa, actualizeaza rulajul). Orice alta
valoare (inclusiv goala) cade pe `'RUL_SURSA'` - e implicit-ul recomandat de Marius (`docs\handoff_
punct6_10082026_seara.md`, decizia 4).

Lasa deschis, READWRITE, cursorul `propunere_sincronizare`:

| camp | tip | continut |
|---|---|---|
| `id_articol` | I | cheia de matching (singura comuna intre `trul`/`tvd`) |
| `denumire` | C(100) | preferata din `tvd` daca articolul exista acolo, altfel din `trul` |
| `codmat` | C(30) | idem |
| `cantitate_veche` | N(12,3) | valoarea curenta din cursorul-**tinta** |
| `cantitate_noua` | N(12,3) | valoarea calculata din cursorul-**sursa** |
| `pret_vechi` | N(14,4) | idem, pret unitar **cu TVA** |
| `pret_nou` | N(14,4) | idem |
| `actiune` | C(12) | `Modificare` / `Adaugare` / `Semnalare` / `N-A` |
| `motiv` | C(80) | populat pe `N-A`/`Semnalare`, si pe `Adaugare` in `ARTICOLE_SURSA` |

Articolele **identice** intre sursa si tinta nu apar in cursor (fara zgomot, ca in propunere.md).

Retur logic: `.F.` doar cand `tvd`/`trul` nu sunt ambele deschise la apel (cursorul iese oricum creat,
gol) - restul cazurilor (0 articole, document fara diferente) intorc `.T.` cu cursorul gol sau partial.

**Agregarea**, per `id_articol`, separat pe `trul` si pe `tvd`, doar randuri `Nvl(sters,0)<>1`:
- RUL: `cant_articol = SUM(cant) + SUM(IIF(id_tip_rulaj<>3, cante, 0))`,
  `val_articol = SUM(cant*pretvtva) + SUM(IIF(id_tip_rulaj<>3, cante*pretvtva, 0))` (formula E.3
  neschimbata), `pret_articol = val_articol/cant_articol`.
- tvd: `cant_articol = SUM(cantitate)`, `val_articol = SUM(valoare)` (coloana `tvd.valoare`, deja
  calculata cu TVA la incarcare/editare - **citita, nu recalculata** - `IncarcaArticoleFactura`,
  `ofacturare_editare.prg:318-320`, e chiar in acest fisier), `pret_articol = val_articol/cant_articol`.

**Actiune**, in ordinea exacta de verificare (prima conditie adevarata castiga):
1. **Documentul e in valuta** (`tvanz.in_valuta<>0`, cand `tvanz` e deschis cu un rand) -> `N-A` pe
   **toate** articolele, indiferent de restul. *Decizie luata in aceasta implementare, nu era in
   propunere.md*: conversia RON<->valuta intre `trul.pretvtva` (presupus RON) si `tvd.pret` (in
   valuta documentului cand documentul e in valuta) nu a fost verificata pe date reale in bugetul
   alocat - mai sigur sa semnalez decat sa scriu o suma gresita. Fara aceasta garda, restul logicii
   (agregare, matching, Modificare/Adaugare/Semnalare) e neschimbata pe documente RON.
2. **Mai multe randuri RUL active pe acelasi articol** (`nrand_rul>1`) -> `N-A`, chiar daca agregatul
   ar fi identic cu tinta (verificat explicit in test, caz A6: o pereche `id_tip_rulaj=3` a carei sume
   egaleaza exact `tvd`, tot N-A) - decizia lui Marius/propunere.md punctul 6, generalizata la ambele
   directii (nu doar la aplicare, ca in propunere.md sectiunea 4 - vezi "Diferente fata de propunere"
   mai jos).
3. **Articol nestocat** (`tvd.in_stoc=0`, doar cand articolul exista in `tvd`) -> `N-A`.
4. **Doar in sursa** -> `Adaugare`.
5. **Doar in tinta** -> `Semnalare` (niciodata stergere automata).
6. **In ambele, diferit** -> `Modificare`; identic -> nu apare in cursor.

## `AplicaSincronizareArticole(tcDirectie, toForm)`

Parametru nou fata de brief: **`toForm`, opus** (contractul descris mai jos, punctul "Ce ramane pe
seama etapei 2"). Reconstruieste propunerea (apeleaza `ConstruiestePropunereSincronizare` intern -
etapa 2 nu trebuie sa o apeleze separat inainte) si aplica **tot ce nu e `N-A`/`Semnalare`** - deci
`Modificare` + `Adaugare`, decizia lui Marius ("fara selectie pe linie"). **Niciun `INSERT`/`UPDATE`
Oracle** - doar `tvd`/`trul` in memorie.

Retur numeric: cate linii au fost efectiv aplicate (nu cate erau in propunere) - formularul il
foloseste ca sa stie daca sa reactualizeze bara de totaluri/gridul.

- **`RUL_SURSA`**: `Modificare` -> `REPLACE tvd.cantitate/pret/discount_unitar` pe primul rand activ
  gasit pe articol, **pastrand `pret_cu_tva` existent pe rand** (pretul propus, mereu cu TVA per E.3,
  se converteste la fara-TVA prin `/proc_tvav` daca randul era asa) - decizie luata acum, nu era in
  propunere.md (care zicea doar "REPLACE ... pret_cu_tva WITH ..." fara sa spuna cu ce): am ales sa
  NU schimb convenția per-rand, ca sa nu inversez brusc semnificatia unei coloane pe care utilizatorul
  a vazut-o intr-un fel; `Adaugare` -> `toForm.AdaugaLinieTvdDinArticol()`, cu obiectul construit din
  `CreeazaPoArticolNouTvd` (tiparul cerut de brief), suprascris cu cantitate/pret din RUL,
  `preturi_cu_tva=1` (linie noua, fara conventie de pastrat), `cont`/`id_gestiune`/`proc_tvav` din
  randul RUL al articolului.
- **`ARTICOLE_SURSA`**: `Modificare` -> `REPLACE` doar `cant` sau `cante` (dupa care era deja populat
  pe rand - verificat in test, caz C1) si `pretvtva`, pe singurul rand RUL activ (garantat unic, altfel
  propunerea a marcat N-A la pasul 2). Nu atinge `id_tip_rulaj`/conturi/campuri derivate
  (`valoare`/`tva`/etc.) - raman de recalculat de apelant daca e nevoie, in afara scopului acestei
  livrari. `Adaugare` -> **nu se aplica niciodata** (niciun rand RUL nou, decizia din propunere.md
  punctul 5.B).

## Ce ramane pe seama etapei 2 - contractul lui `toForm`

Am ales varianta **"primesc obiectul formular ca parametru"**, nu "duplic tiparul separat". Fara
`toForm` (sau un obiect care nu implementeaza metodele), `AplicaSincronizareArticole` tot face
`REPLACE`-ul de baza pe `tvd` pentru `Modificare` (verificat in test, caz B2), dar:
- **nu recalculeaza `tvd.valoare`** (ramane cea veche pana la un recalcul extern);
- **nu cheama `ActualizeazaBaraTotaluri`**;
- **sare complet liniile `Adaugare`** (fara `toForm.AdaugaLinieTvdDinArticol`, nu exista alta cale sa
  adauge linia fara sa duplice acel helper).

Deci etapa 2 (butonul/dialogul din PAGE3) **trebuie sa apeleze `AplicaSincronizareArticole(tcDirectie,
Thisform)`**, cu `Thisform` fiind instanta `frm_modific2024` deja incarcata (are ambele metode:
`calculeaza_valori_articol`, `AdaugaLinieTvdDinArticol`). Contractul verificat prin `Pemstatus()`, nu
presupus - un obiect fara aceste metode e tratat exact ca "fara toForm".

## Diferente fata de `propunere_s4b_sincronizare.md` - de confirmat cu Marius/etapa 2

1. **Documentele in valuta sunt N-A pe tot** (mai sus, punctul 1 al ordinii de actiune) - propunere.md
   nu mentiona deloc valuta pentru S4b. Scop deliberat restrans: fara o verificare pe un document real
   in valuta CU randuri RUL, nu am vrut sa livrez o conversie neverificata. Daca Marius vrea si
   documentele in valuta acoperite, e nevoie de o cercetare separata (confirmarea daca `trul.pretvtva`
   e RON sau in valuta proprie a randului RUL - `VRUL_TOT` are propriile `CURS`/`ID_VALUTA` per rand,
   verificat prin `DESCRIBE`, dar nu s-a confirmat ce inseamna practic pentru `PRETVTVA`).
2. **"Mai multe randuri RUL active" e N-A in ambele directii, la nivelul propunerii** (nu doar la
   aplicarea `ARTICOLE_SURSA`, cum sugera propunere.md sectiunea 4) - generalizare ceruta explicit de
   briefing-ul acestei sarcini ("niciodata alegere automata a randului", listat ca regula a
   `ConstruiestePropunereSincronizare`, nu doar a aplicarii). Efect: pe un document cu perechi
   `id_tip_rulaj=3` (diferenta de pret la marfa/produse la pret de vanzare, `rec_suma_act.md` E.1),
   articolul respectiv ram**a** mereu N-A, chiar daca suma agregata (E.3) ar fi corecta si identica -
   propunerea nu ofera Modificare/Adaugare automata pe acele articole, doar afisare informativa.
3. **`tvd` cu mai multe randuri active pe acelasi articol nu are o garda separata** - `AplicaModificare
   Tvd` scrie pe **primul** rand activ gasit. Cazul e rar (articol adaugat de doua ori manual pe
   aceeasi factura) si n-a fost cerut explicit in briefing; il semnalez ca limitare cunoscuta, nu l-am
   tratat ca sa nu extind scopul peste ce s-a cerut.

## Teste

`COMUN\utile\Teste\editare_factura\test_s4b_sincronizare.prg`, model `test_s5_validari_articole.prg`.
Complet headless, **fara Oracle** - nici `ConstruiestePropunereSincronizare`, nici
`AplicaSincronizareArticole` nu ating `goExecutor`, deci testul nu are nevoie de `test_init_env_auto`/
conexiune - doar `SET PROCEDURE TO ofacturare_editare.prg` si `gnPC` setat manual. `tvd`/`trul` sunt
construite direct in test (helpere `AdaugaTvd`/`AdaugaTrul`); `trul` e o structura minimala (doar
campurile citite de cod), nu cele 218 coloane reale ale `VRUL_TOT`.

Cazuri acoperite (sectiunea A - `ConstruiestePropunereSincronizare`, cate un caz pe ambele directii
unde se aplica): identic (A1), modificare cu valori inversate corect intre directii (A2), doar-in-
sursa/doar-in-tinta -> Adaugare/Semnalare cu roluri schimbate intre directii (A3/A4), articol nestocat
(A5), mai multe randuri RUL active - N-A chiar cand agregatul ar fi identic (A6), randuri `sters`
excluse din agregare pe ambele cursoare (A7), document in valuta -> N-A pe tot (A8), tvd/trul lipsa la
apel (A9). Sectiunea B (`AplicaSincronizareArticole`, `RUL_SURSA`): aplicare completa cu `toForm`
(Modificare + Adaugare, verificate valorile scrise in `tvd` si apelurile pe test-double, semnalare/N-A
neatinse - B1), **fara** `toForm` (Adaugare sarita fara eroare, Modificare tot se aplica - B2),
pastrarea conventiei `pret_cu_tva=0` cu conversia pretului propus (B3). Sectiunea C
(`AplicaSincronizareArticole`, `ARTICOLE_SURSA`): `cant` vs `cante` pastrat dupa care era populat pe
rand, Adaugare niciodata scrisa in `trul` (C1).

`test-double`-ul `dummyform` (definit la finalul fisierului, tipar identic cu `dummyexecutor` din
`test_s5_validari_articole.prg`) oglindeste EXACT formula din `calculeaza_valori_articol`/
`AdaugaLinieTvdDinArticol` - verifica ca `AplicaSincronizareArticole` cheama metodele corecte cu
argumentele corecte, fara sa deschida formularul real sau sa atinga vreun `.vc2`.

**Capcana gasita si reparata in acest bloc**: comparatii `==` intre un camp `Character` de latime
fixa (`actiune`, C(12)) si un literal mai scurt (`'Modificare'`) esueaza mereu din cauza spatiilor de
umplere din dreapta - VFP `==` e comparatie stricta, nu trece prin `SET EXACT`. Aparea atat in codul
de productie (`AplicaSincronizareArticole`, filtrul `SCAN FOR Inlist(actiune,...)` si `DO CASE`), cat
si in asertiunile testului. Reparat cu `Alltrim()` pe partea citita din camp, in ambele fisiere.

**Cifra din log** (`test_s4b_sincronizare_log.txt`, rulare `vfp9.exe -A -T`):

```
REZULTAT: 35 PASS / 0 FAIL
```

Toate testate (headless, cursoare construite in test) - niciun caz "doar analizat static". Nu s-a
verificat pe un document real din Oracle (nu era ceruta si nici necesara pentru logica pura), si nici
comportamentul pe un document real in valuta (vezi punctul 1 din "Diferente fata de propunere" -
scop restrans deliberat).

## Ce lipseste pentru punctul #6 complet (etapa 2, alt agent)

1. Butonul `cmdSincronizeazaArticole` in PAGE3 si toggle-ul de `Enabled` in `Show()`
   (`omodificari.vc2`, punctul 1 din propunere.md).
2. Dialogul modal `frm_sincronizare_articole` (radio pe directie, grid needitabil pe
   `propunere_sincronizare`, Aplica/Renunta) - punctele 2-3 din propunere.md.
3. Verificarea la salvare (`inainte_de_do_termin`) care ofera enumerarea si permite salvarea mai
   departe fara sincronizare - decizia 2 a lui Marius (`docs\handoff_punct6_10082026_seara.md`).
4. Apelul `AplicaSincronizareArticole(tcDirectie, Thisform)` din dialog, la "Aplica", si reactualizarea
   gridului/barei de totaluri folosind numarul de linii aplicate intors.