docs: cercetarile comune trec in COMUN, reziduul #6 dispare, progres.md la zi

Curatenie ceruta dupa inchiderea lui #6. Folderul cercetare\ NU se putea sterge
in bloc: plan_13 se sprijina pe el cu 85 de trimiteri, deci e baza de dovezi a
planului aflat in lucru. Impartirea:

- 14 cercetari trans-proiect trec in COMUN\docs\cercetare\ - valuta si curs,
  TVA/VANZARI, consumatorii VANZARI din toata suita, integrarile #10/#11/#12,
  watchdog VFP, proiectarea Oracle a lui S5, view-ul VVANZARI_ARTICOLE. Nu sunt
  ale ROAFACTURARE, iar #10/#11/#12 se reiau chiar din ele.
- 20 de rapoarte de executie ale lui #6, nereferite de nimic viu, sterse.
- 91 raman, neatinse.

Trimiterile catre handoff-urile si diff-urile intermediare deja desfiintate au
fost curatate peste tot (39 de fisiere): 50 catre handoff-uri, 37 catre diff-uri
aplicate, plus caile celor mutate in COMUN. Zero trimiteri rupte ramase.

progres.md preia rolul de predare: ce ramane din #6 (cele sase documente
parazite, cele doua esecuri reale din S8 pe factura din aviz), cifrele de test
citite din log, si cele doua capcane de mediu platite - .FXP vechi executat in
locul .prg-ului, si GETFONT() care atarna un formular instantiat fara goApp.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SN8snvkk94KuhWwoXUUey3

docs/plan_13_unificare_formular_facturare.md

@@ -3517,6 +3517,34 @@ luna inchisa, referentiate, sau care au urmasi (retur, factura din aviz, factura
 > il inchide** — cele doua se unifica, nu se aleg. Din intrebarea 7 ramane deschisa **numai** partea de
 > tipuri 48/49.
 
+> **CERINTA DE EXECUTIE ADAUGATA IN RUNDA 17 — `IN_STOC` se incarca din document, nu din nomenclator.**
+> Vine din consecinta 1 a deciziei 54 (vezi S10, „Trei consecinte"), si se prinde **aici**, nu la S12.
+> Cu flag-ul de regenerare pornit, `IN_STOC` nu mai e re-derivat de `adauga_articol_factura`, ci **vine
+> din formular** — deci valoarea pe care o incarca S8 devine valoarea care decide **descarcarea de
+> gestiune la reemitere**. Azi loader-ul lui #6 o citeste din nomenclatorul curent
+> (`ofacturare_editare.prg:302-303`), deci un articol devenit intre timp gestionabil (sau invers) ar
+> face reemiterea sa atinga **alt stoc decat documentul initial**, tacut.
+>
+> Trei consecinte concrete pentru canalul de citire (intrebarea 1 din §8.2, *recomandat* (B),
+> `cursor_editare_document`):
+> - canalul trebuie sa intoarca `IN_STOC` **asa cum a fost la emitere**, nu `GESTIONABIL = B.IN_STOC`
+>   din nomenclatorul de azi, cum face `cursor_retur_document` (`PACK:3993-4000`). E un **al treilea
+>   argument** pentru procedura noua, langa `ID_VANZARE_DET` / `TAXCODE` si langa `ID_POL` / `ID_CTR`
+>   lipsa din `VVANZARI_ARTICOLE`;
+> - **valoarea istorica nu e stocata nicaieri**: `IN_STOC` nu e coloana pe `VANZARI_DETALII` (verificat
+>   pe DB, vezi S10), traieste doar in temp. Deci primul pas al lui S8 pe aceasta cerinta e sa
+>   stabileasca **de unde se reconstituie** — fie din urma lasata in rulaje / gestiune pentru documentul
+>   respectiv, fie se accepta nomenclatorul curent ca aproximatie **declarata explicit**, fie se adauga
+>   coloana (migrare DB, deci **DB inainte de EXE**, ca la S10). **Nu se presupune niciuna dintre
+>   variante**; e o **preconditie de proiectare a lui S8**, nu un detaliu de implementare;
+> - pe tipurile **48/49** cerinta se intalneste cu decizia 60: acolo invariantul e `IN_STOC = 0` prin
+>   constructie, deci valoarea incarcata trebuie sa fie `0` indiferent ce zice nomenclatorul azi.
+>
+> *Criteriu de test (intra in „gata cand" al lui S8):* un document emis cu un articol caruia i s-a
+> schimbat intre timp `IN_STOC` in nomenclator, deschis in formular, poarta **valoarea de la emitere**;
+> iar reemiterea lui lasa **stocul agregat neschimbat** (masurat inainte / dupa, nu prin inspectia
+> codului).
+
 > **Cerinta noua din S8b e mai blanda decat se credea:** lookup-ul „ultimul delegat / ultima masina"
 > **are deja o garda** — `Empty(id_delegat) And Empty(id_masina)` (`ferestre_cere_date.vc2:3111`).
 > Riscul ramane real, dar **numai** pe documentele fara delegat si fara masina. Raportul da inventarul
@@ -3537,7 +3565,8 @@ Formularul arata **identic** cu cel de introducere: fara banda de avertizare, fa
 valorile initiale, fara panou de diferente (decizia 5). Se schimba titlul ferestrei si **butonul
 principal** (decizia 9, vezi S8c).
 *Gata cand:* formularul deschis pe un document existent arata exact documentul, pe fiecare tip de
-sursa, si nu se distinge vizual de formularul de introducere.
+sursa, si nu se distinge vizual de formularul de introducere; **si** liniile incarcate poarta `IN_STOC`
+de la emitere, nu din nomenclatorul de azi (cerinta rundei 17, mai sus).
 *Depinde de:* S7.
 
 #### S8b — Rutarea scrierii dupa ce s-a schimbat
@@ -3878,6 +3907,9 @@ comportament nou:
    **comportamentul de stoc** al reemiterii. Ca reemiterea sa fie identica, **S8 trebuie sa incarce
    valoarea cu care s-a scris documentul initial** — si **azi nu o incarca**: loader-ul lui #6 o citeste
    din nomenclatorul curent (`ofacturare_editare.prg:302-303`). **Flag-ul singur nu rezolva asta.**
+   **PRELUAT (runda 17) ca cerinta de executie in S8**, cu cele trei consecinte pentru canalul de citire
+   si criteriul de test — vezi caseta „CERINTA DE EXECUTIE ADAUGATA IN RUNDA 17" din S8. Aici nu mai e
+   nimic de decis.
 2. **Se pierde o validare pe ramura comenzi.** Azi, `A.PRET = V_PRET_TEMP` + lipsa lui `EXCEPTION` fac
    ca o linie care nu se mai potriveste cu comanda sa **opreasca** scrierea. Cu flag-ul pornit,
    reemiterea unei facturi din comanda nu mai verifica linia fata de comanda. Decizia 54 pare sa vrea