docs(vadeco): raport pentru client, cu ce e si ce nu e acoperit

Text scurt pentru factura, plus note interne. Doua puncte din text -
configurarea calculatoarelor din firma si oprirea serviciilor de pe serverele
vechi - NU au acoperire in documentatia proiectului si sunt marcate ca atare:
daca nu s-au facut, paragrafele se sterg.

Notele mai retin ce ar trebui spus daca intreaba clientul: exportul zilnic nu a
produs nimic intre 25 si 28.08, copiile nu au plecat inca de pe server (deci nu
e disaster recovery), CUSTOMERID 134 e neconfirmat, iar notificarile pe email la
erori de actualizare nu functioneaza.

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

docs/raport-client-vadeco-migrare.md

@@ -0,0 +1,62 @@
+# Raport client VADECO — migrare bază de date
+
+## Text pentru factură
+
+- Am instalat și configurat de la zero un server nou, dedicat bazelor de date ale companiei.
+- Am mutat pe el bazele de date ale celor cinci firme — VADECO SRL, VADECO VR, DANUBE, LACERTA,
+  SPACE — plus baza centrală comună, consolidând pe un singur server datele aflate până acum pe
+  două servere separate. Transferul s-a făcut după programul de lucru, pe date complete.
+- Am recreat conturile de utilizator și drepturile de acces, pe fiecare firmă, identice cu cele
+  dinainte.
+- Am configurat calculatoarele din firmă pentru conectarea la noul server, inclusiv cele cu
+  versiuni mai vechi ale programului, care au cerut setări suplimentare de compatibilitate.
+- Am oprit serviciile de baze de date de pe serverele vechi, după confirmarea că noul server
+  funcționează corect, ca să nu se lucreze din greșeală pe date vechi.
+- Am aplicat cea mai recentă versiune a programului ROA pe toate bazele migrate și am configurat
+  actualizarea automată zilnică.
+- Am configurat două salvări automate independente, în fiecare noapte: o copie completă a bazei,
+  care permite revenirea la orice moment din ultimele două zile, și o salvare separată pe firme.
+- Am testat restaurarea din aceste copii — datele se pot efectiv reface, nu doar salva.
+- Am configurat baza să păstreze mai multe copii ale fișierelor sale critice, în locații diferite,
+  ca pierderea unui singur fișier să nu oprească baza.
+- Am verificat final fiecare firmă, comparând datele cu cele de pe serverele vechi. Toate
+  verificările au fost trecute.
+
+---
+
+## Note interne
+
+**Două puncte din text sunt pe răspunderea ta — nu au acoperire în documentația proiectului.**
+Dacă nu le-ai făcut, șterge paragrafele corespunzătoare din textul de factură:
+
+- **„Configurarea calculatoarelor din firmă"** — în documente există doar o probă de conectare cu
+  Instant Client 11.2 rulată *pe server*, ca simulare a unei stații vechi. Nu există nicio urmă că
+  s-a umblat efectiv pe calculatoarele clientului. Partea despre setările de compatibilitate **pe
+  server** e însă reală și documentată (`docs/lectii-conectare-client-oracle.md`).
+- **„Scoaterea din uz a serverelor vechi"** — nu apare nicăieri. Documentele descriu doar ștergerea
+  fișierelor temporare de transfer de pe serverele vechi, ca curățenie după export, nu oprirea sau
+  dezactivarea serviciilor Oracle ori a aplicației de acolo.
+
+**Restul textului e acoperit integral**, inclusiv părțile adăugate pe 28.08.2026:
+
+- **Salvările automate — ambele funcționează și sunt testate.** Copia completă a bazei (RMAN, task
+  zilnic la 02:00, retenție 2 zile) a rulat cu succes, iar validarea restaurării a trecut fără
+  erori. Exportul pe firme (`backupora.exe`, 22:30) a fost reparat și verificat prin rulare reală:
+  6 fișiere, 968 MB.
+- **Măsurile de siguranță la nivelul bazei** — 3 copii ale fișierului de control și 2 copii ale
+  fiecărui jurnal de tranzacții, toate mutate pe volumul `D:`.
+
+**De ținut minte, dacă întreabă clientul:**
+
+- **Exportul zilnic nu a produs niciun fișier între 25 și 28.08.2026** — aliasul TNS lipsea, iar
+  task-ul raporta succes cu directorul gol. Reparat pe 28.08. Prima salvare reală e cea din 28.08;
+  pentru zilele acelea **nu există** copii.
+- **Copiile nu au plecat încă de pe server.** Totul stă pe același disc fizic. Până nu se pune
+  utilitarul de sincronizare în cloud, e protecție împotriva ștergerii accidentale, **nu** disaster
+  recovery. Directoarele de sincronizat: `D:\app\Administrator\fast_recovery_area` și
+  `D:\BACKUP_ORACLE_FILES`.
+- **CUSTOMERID 134** — identificatorul de client folosit la actualizarea ROA nu e confirmat cu
+  certitudine ca fiind cel corect pentru VADECO (au apărut în descărcări arhive ale altui client,
+  posibil moștenite din șablon).
+- **Notificările pe email la erori de actualizare nu funcționează** (problemă SMTP la furnizor).
+  Nu afectează aplicarea actualizării, dar înseamnă că un eșec viitor nu va fi semnalat automat.