roafacturare/docs/cercetare/idfact_refolosire_si_documente.md

Cercetare S9: reemiterea unui document cu acelasi ID_FACT (SET_IDFACT + DOCUMENTE)

Verdict (rezumat)

DA, dar cu conditii — nu e o schimbare izolata. SET_IDFACT activ (PACK_CONTAFIN.pck:3037-3040) ia neconditionat un ID_FACT nou din SEQ_IdFact; niciun apelant din toata suita (~25-30 copii identice ale oscrie_in_fisiere.prg, cate una per produs) ii impune un ID_FACT. Varianta comentata (:3016-3035, cauta pe NRACT+SERIE_ACT+DATAACT+ID_CTR cu STERS=0) nu rezolva S9 ca atare: dupa stergerea soft a documentului vechi, STERS e deja 1, cautarea nu-l gaseste, si cade tot pe secventa — plus riscul de coliziune cu un document viitor neinrudit care are aceleasi 4 campuri. Blocajul real nu e in SET_IDFACT, ci in scrierea din DOCUMENTE: acolo e un INSERT simplu (:796-817) pe ID_DOC, care e PRIMARY KEY (PK_DOCUMENTE, unic, fn_script.sql:5192-5198). Stergerea (STERGE_DIN_ACT:1835-1855) e soft-delete pur — ACT.STERS=1, apoi DOCUMENTE.STERS=1 pentru id_fact-urile gasite pe acel COD — randul vechi nu se sterge fizic. Deci reemiterea cu acelasi ID_FACT, cu codul de azi neschimbat, ar arunca ORA-00001 la insertul in DOCUMENTE, pentru ca randul cu acel ID_DOC inca exista (doar marcat STERS=1). Varianta MERGE deja comentata (:818-847) nu ajuta din prima: are doar WHEN NOT MATCHED, fara WHEN MATCHED, deci daca randul exista deja l-ar ignora tacit — documentul reemis ar ramane cu DOCUMENTE.STERS=1. Concluzie operationala: reutilizarea e posibila, dar cere trei schimbari simultane (detaliate la C.7), nu doar reactivarea codului comentat din SET_IDFACT.

A. SET_IDFACT

A.1 — Ramura activa vs. ramura comentata

Cod integral, PACK_CONTAFIN.pck:3014-3040:

  ------------------------------------------------------------------------------------
  /* -- 25.02.2013 : am comentat pentru ca se face unirea id_fact pe listarea din JC/JV
    PROCEDURE SET_IDFACT(tdDataAct   ACT_TEMP.DATAACT%TYPE,
                       tcSerie_Act ACT_TEMP.SERIE_ACT%TYPE,
                       tnNrAct     ACT_TEMP.NRACT%TYPE,
                       tnId_Ctr    ACT_TEMP.ID_CTR%TYPE) IS
    V_ID_FACT DOCUMENTE.ID_DOC%TYPE;
  BEGIN
    BEGIN
      SELECT ID_DOC
        into pack_contafin.nIdFact
        FROM DOCUMENTE
       WHERE NRACT = tnNrAct
         AND NVL(SERIE_ACT, '+-') = NVL(tcSerie_Act, '+-')
         AND DATAACT = tdDataAct
         AND NVL(ID_CTR, 0) = NVL(tnId_Ctr, 0)
         AND STERS = 0;
    EXCEPTION
      WHEN NO_DATA_FOUND THEN
        SELECT SEQ_IdFact.NEXTVAL into pack_contafin.nIdFact FROM DUAL;
    END;
  END SET_IDFACT;*/
  ------------------------------------------------------------------------------------
  PROCEDURE SET_IDFACT(V_GCS IN VARCHAR2) IS
  BEGIN
    SELECT SEQ_IdFact.NEXTVAL into pack_contafin.nIdFact FROM DUAL;
  END SET_IDFACT;

Diferenta de comportament daca s-ar reactiva varianta comentata: in loc sa genereze mereu un ID_FACT nou, ar cauta intai in DOCUMENTE un document nesters (STERS=0) cu aceeasi combinatie NRACT + SERIE_ACT + DATAACT + ID_CTR, si doar daca nu gaseste nimic ar cere secventa. Doua probleme pentru S9:

• nu se aplica la reemitere: documentul vechi e deja marcat STERS=1 inainte de rescriere (vezi B.6), asa ca filtrul STERS=0 nu-l gaseste — cade tot pe SEQ_IdFact.NEXTVAL, exact ca azi;
• risc de coliziune: daca NRACT/SERIE_ACT/DATAACT/ID_CTR ar coincide intamplator cu alt document nesters (nu neaparat cel pe care il reemitem), i-ar imprumuta ID_FACT-ul aceluia. Semnatura veche are 4 parametri de identitate diferiti de semnatura activa (1 parametru V_GCS, folosit doar ca "user"/context, nefolosit in corp) — deci reactivarea ar cere fie o supraincarcare, fie schimbarea semnaturii peste tot unde e chemata (vezi A.2).

A.2 — Apelanti

Un singur punct de apel in PL/SQL: PACK_CONTAFIN.pck:721, in bucla din SCRIE_IN_ACT:

      pack_contafin.set_idfact(V_GCS);
      /* 25.02.2013 : se face cumularea id_fact pe listarea din RC/RJ
      PACK_CONTAFIN.SET_IDFACT(itemfact.dataact, itemfact.serie_act, itemfact.nract, itemfact.id_ctr);*/
      lnIdFact := get_idFact();

buclat pe grupuri distincte (NRACT, DATAACT, DATAIREG, SERIE_ACT, ID_CTR, ID_SET) extrase din ACT_TEMP WHERE ID_FACT = -1 (:713) — deci -1 e sentinela "acest rand cere un ID_FACT nou".

SCRIE_IN_ACT insusi e apelat doar pe drumul de scriere, niciodata pe cel de stergere — in finalizeaza_scriere_act_rul (:8449-8459):

    if tnScrieSterge <> 2 then
      pack_contafin.SCRIE_IN_ACT(user);
      ...
    else
      pack_contafin.STERGE_DIN_ACT(user, lnAn, lnLuna, tnCod, tnIdUtil, tnModificareNota);
      ...

Deci SET_IDFACT nu se atinge deloc la stergere — confirma ca azi cele doua operatii (stergere + reemitere) sunt independente unele de altele in privinta ID_FACT.

Cine cheama final_scriere_act_rul_local / SCRIE_IN_ACT din VFP: acelasi fisier COMUN\programe\oscrie_in_fisiere.prg, replicat identic in ~25-30 produse ROA (verificat prin grep pe *.prg in tot D:\ROA): ROAFACTURARE, ROACONT (output), ROAGEST, ROAIMOB, ROAEFACTURA, ROADEVIZE, ROAVIN, ROACASA, ROASAL, ROAPRETURI, ROAOBINV, ROARESTAURANT, ROACOMENZI, ROAAPROV, ROASITOP, ROASITFIN, ROADECL, ROASALSPEC, ROABAVERT, ROACONIMPORT, ROAPRINT, s.a. — plus doua variante care apeleaza SCRIE_IN_ACT direct, fara wrapper-ul local: CONTAFIN2ORA\VFP2ORA\Programe\oscrie_in_fisiere.prg:367, ROADEFSALARII\COMUN\programe\oscrie_in_fisiere.prg:141, ROARESTAURANTCONFIG\COMUN_ROA\programe\oscrie_in_fisiere.prg:135. Un al doilea import vechi (COMUN\datemenu\xold\import_xdbf\oscrie_in_fisiere.prg) apare in multe produse dar e comentat integral (*!*) — inactiv.

Niciun apelant nu impune un ID_FACT. Toti trimit ID_FACT = -1 in ACT_TEMP (via sql_temp_insert in oscrie_in_fisiere.prg:126-137, care copiaza direct campurile din cursorul VFP, inclusiv id_fact) si lasa SCRIE_IN_ACT sa-l completeze din secventa. Confirmare suplimentara in COMUN\clase\omodificari.vc2:4131-4132: "daca se schimba partenerul, se pune id_fact = -1 in loc de 0 pentru a se putea genera un nou id_fact" — exact sentinela pe care se bazeaza bucla din SCRIE_IN_ACT.

A.3 — Variabila/parametru existent pentru un ID_FACT dorit

Nu exista azi. PACK_CONTAFIN are o variabila de pachet nIdFact (setata de SET_IDFACT, citita de GET_IDFACT), dar e scrisa neconditionat de fiecare apel al lui SET_IDFACT — nu poate fi folosita ca "intrare" fara sa se schimbe corpul procedurii. Nu exista niciun nid_... global, nici alt parametru de sesiune care sa transmita un ID_FACT dorit lui SET_IDFACT sau lui SCRIE_IN_ACT. Ar trebui adaugata o variabila noua de pachet (ex. un "ID_FACT fortat", implicit NULL), citita doar in corpul activ al lui SET_IDFACT, consumata si resetata la prima folosire — vezi C.8. Acelasi diagnostic e deja notat in planul de proiect, plan_13_unificare_formular_facturare.md:1717-1719: "ID_FACT. Se citeste inainte de stergere ... si se impune documentului nou, printr-un comutator folosit numai de regenerare. SET_IDFACT nu se schimba neconditionat — e cod comun intregii suite."

B. DOCUMENTE la reemitere cu acelasi ID_FACT

B.4 — INSERT sau UPDATE/MERGE azi

PACK_CONTAFIN.pck:788-817, in interiorul buclei din SCRIE_IN_ACT, cod activ (INSERT simplu):

      -- SCRIE IN DOCUMENTE
      lnTvaIncasare := case when itemfact.tva_incasare > 0 then 1 else 0 end;
      -- 25.02.2013 : am repus insertul pentru ca se face cumularea id_fact pe listarea din RC/RJ
      INSERT INTO DOCUMENTE
        (ID_DOC, ID_UTIL, DATAORA, TVA_INCASARE, SERIE_ACT, NRACT, DATAACT, DATAIREG, ID_CTR, ID_SET)
      VALUES
        (lnIdFact, lnID_Util, LD_DATAORA, lnTvaIncasare, itemfact.serie_act, itemfact.nract,
         itemfact.dataact, itemfact.dataireg, decode(itemfact.id_ctr, 0, NULL, itemfact.id_ctr),
         itemfact.id_set);
      /*
      -- modificare ROACONT v 2.4.0 (27.12.2012): am adaugat serie_act, nract, dataact
      -- modificare 21.02.2013: am adaugat id_ctr
      MERGE INTO DOCUMENTE A
      USING (SELECT lnIdFact as ID_DOC, itemfact.serie_act as SERIE_ACT, itemfact.nract as NRACT,
                    itemfact.dataact as DATAACT,
                    decode(itemfact.id_ctr, 0, NULL, itemfact.id_ctr) AS ID_CTR
               FROM DUAL) B
      ON (A.ID_DOC = B.ID_DOC)
      WHEN NOT MATCHED THEN
        INSERT (ID_DOC, ID_UTIL, DATAORA, TVA_INCASARE, SERIE_ACT, NRACT, DATAACT, ID_CTR)
        VALUES (B.ID_DOC, lnID_Util, LD_DATAORA, lnTvaIncasare, B.SERIE_ACT, B.NRACT, B.DATAACT, B.ID_CTR);*/

Deci azi e mereu un INSERT nou — pe drumul normal (ID_FACT vine din secventa, mereu inexistent in DOCUMENTE) asta e corect, dar pentru cazul S9 (ID_FACT reutilizat, deja existent — chiar si soft-sters) INSERT-ul ar da eroare de unicitate (vezi B.5). Varianta MERGE comentata are doar WHEN NOT MATCHED — daca s-ar reactiva neschimbata, un ID_DOC deja existent ar fi pur si simplu ignorat (fara WHEN MATCHED), documentul reemis ramanand cu randul vechi din DOCUMENTE (cu TVA_INCASARE/ID_SET nemodificate si, mai grav, cu STERS neresetat — vezi B.6).

B.5 — Constrangere de unicitate pe DOCUMENTE

DDL gasit in D:\ROA\DATABASE\ALTELE\Creare_server_scripturi\FirmaNoua\fn_script.sql:5162-5198:

CREATE TABLE "DOCUMENTE" ("ID_DOC" NUMBER(20, 0) NOT NULL ENABLE, "DATAORA" DATE NOT NULL ENABLE,
  "ID_UTIL" NUMBER(5, 0) NOT NULL ENABLE, "STERS" NUMBER(1, 0) NOT NULL ENABLE,
  "DATAORAS" DATE, "ID_UTILS" NUMBER(5, 0) NOT NULL ENABLE) ...
...
CREATE UNIQUE INDEX "PK_DOCUMENTE" ON "DOCUMENTE" ("ID_DOC") ...
ALTER TABLE "DOCUMENTE" ADD CONSTRAINT "PK_DOCUMENTE" PRIMARY KEY ("ID_DOC") USING INDEX ... ENABLE

Da: ID_DOC e PRIMARY KEY, unic. (Coloanele SERIE_ACT/NRACT/DATAACT/DATAIREG/ID_CTR/ID_SET/ TVA_INCASARE din INSERT-ul de la B.4 nu apar in acest script — script vechi de firma noua, probabil tabela a fost alterata ulterior cu ALTER TABLE ADD COLUMN; constrangerea de PK insa e stabila si nu are motiv sa fi fost scoasa.) Un INSERT INTO DOCUMENTE (ID_DOC=...) cu o valoare de ID_DOC care exista deja (chiar si STERS=1) arunca ORA-00001: unique constraint (PK_DOCUMENTE) violated. Nu am gasit alta constrangere de unicitate pe DOCUMENTE; nici FK de la ACT.ID_FACT catre DOCUMENTE.ID_DOC (ACT.ID_FACT e doar indexat, IDX_ID_FACT, fn_script.sql:1637, fara constrangere de integritate referentiala gasita) — deci reinserarea de randuri in ACT cu ID_FACT reutilizat nu e blocata de vreo constrangere pe ACT insusi; blocajul e exclusiv pe DOCUMENTE.

B.6 — Randurile vechi la stergere: fizic sterse, STERS=1, sau raman

Soft-delete pur, pe toate cele patru tabele relevante — nimic nu se sterge fizic.

STERGE_DIN_ACT (PACK_CONTAFIN.pck:1815-1859), apelata din finalizeaza_scriere_act_rul cand tnScrieSterge = 2:

  PROCEDURE STERGE_DIN_ACT(V_GCS VARCHAR2, tnAn in number, tnLuna in number, tnCod in number,
                           tnId_utils in number, tnTip IN NUMBER) is
    -- tnTip : 0 = modificare ; 1 = stergere
    ...
  BEGIN
    ...
    UPDATE /*+ index(ACT IDX_COD) */ ACT
       SET STERS = 1, DATAORAS = LD_DATAORA, ID_UTILS = lnId_util
     WHERE COD = tnCod and an = tnAn and luna = tnLuna;

    IF lnTip = 1 THEN
      UPDATE DOCUMENTE
         SET STERS = 1, ID_UTILS = LNID_UTIL, DATAORAS = LD_DATAORA
       WHERE ID_DOC IN
             (SELECT /*+ index(ACT IDX_COD) */ DISTINCT ID_FACT
                FROM ACT
               WHERE COD = tnCod and an = tnAn and luna = tnLuna
                 AND ID_FACT <> 0
                 and ID_SET not in (90501, 90021)
                 AND NOT (SCD = '4426' AND SCC = '4428')
                 AND NOT (SCD = '4428' AND SCC = '4427'));
    END IF;

    update act_temp set suma = -suma, suma_val = -suma_val;
  END STERGE_DIN_ACT;

ACT -> STERS=1 (randurile raman fizic, pe acelasi COD). Cand tnTip=1 (stergere, nu simpla modificare), DOCUMENTE primeste si el STERS=1, pentru toate ID_FACT distincte gasite pe acel COD in ACT (cu exceptiile de mai sus pentru seturi/conturi speciale). Nicaieri nu am gasit un UPDATE DOCUMENTE ... SET STERS = 0 — cautare exhaustiva in PACK_CONTAFIN.pck (grep -i "UPDATE DOCUMENTE") a dat un singur rezultat, cel de mai sus. Deci nu exista azi niciun mecanism care sa "reinvie" un rand din DOCUMENTE.

La fel, STERGE_DIN_RUL / STERGE_DIN_RUL_OBINV (:1861-1893) fac UPDATE ... SET STERS = 1 pe RUL/RUL_OBINV, fara stergere fizica.

Pentru IREG_PARTENERI si JV2007 situatia e diferita in mod util pentru S9: acestea nu sunt copii 1:1 ale documentului, ci agregate recalculate prin MERGE pe chei de business (an, luna, cont / ID_FDOC, ID_FACT, NRACT, SERIE_ACT, DATAACT, DATAIREG, ID_PART, ...) — vezi SCRIE_JV_2007 (:3328-3373+) si SCRIE_IN_IREG_PARTENERI/EXECUTA_SCRIE_IN_IREG (:7030+, :7607+). Ambele sunt apelate si pe drumul de scriere, si pe cel de stergere (finalizeaza_scriere_act_rul:8495-8578, fara conditie pe tnScrieSterge in afara sursei: act_temp la scriere/stergere, act la refacere). La stergere, sterge_document (:7699-8118) reinsereaza in ACT_TEMP copii ale randurilor vechi din ACT/RUL/RUL_OBINV, cu acelasi ID_FACT ca inainte (coloana id_fact e copiata direct din sursa, nu resetata la -1), asa ca MERGE-ul din SCRIE_JV_2007/SCRIE_IN_IREG_PARTENERI recalculeaza (compenseaza) exact randul cu acel ID_FACT — nu creeaza duplicate. Deci reutilizarea ID_FACT-ului nu produce dubluri in JV2007/ IREG_PARTENERI; problema e strict izolata la DOCUMENTE.

Nota din plan, care confirma independent aceasta zona de risc: plan_13_unificare_formular_facturare.md:1737: "De verificat si daca DOCUMENTE primeste un al doilea rand pe acelasi ID_DOC sau il refoloseste." — raspunsul, dupa aceasta cercetare: niciuna din cele doua, in starea actuala a codului — ar arunca eroare de unicitate, nu ar produce liniste tacuta cu duplicat sau refolosire.

C. Verdictul care conteaza

C.7 — Se poate reemite cu acelasi ID_FACT fara sa se strice nimic?

DA, dar cu conditii — niciuna dintre ele nu e implementata azi:

1. Nu folosi varianta comentata a lui SET_IDFACT ca atare. Cautarea STERS=0 nu gaseste documentul (deja sters soft inainte de rescriere) si e vulnerabila la coliziuni pe chei de business partajate cu alt document. In loc de cautare, ID_FACT-ul trebuie citit explicit inainte de stergere (VFP il are deja in cursorul documentului editat) si transmis pe drumul de scriere — exact ce zice planul S9.
2. SET_IDFACT are nevoie de o cale de intrare noua, inerta implicit. O variabila de pachet noua (ex. "ID_FACT fortat", NULL default) + o procedura noua de setat-o explicit inainte de scriere; corpul activ al SET_IDFACT verifica intai variabila, o consuma si o reseteaza; daca e NULL (cazul general — toate celelalte ~25-30 apeluri din suita), comportamentul e identic cu azi (secventa). Nu se toarna in semnatura existenta SET_IDFACT(V_GCS), ca sa nu se schimbe apelul de la niciun alt caller.
3. Scrierea in DOCUMENTE trebuie sa devina un upsert real, cu WHEN MATCHED. Nici INSERT-ul activ, nici MERGE-ul comentat (fara WHEN MATCHED) nu revigoreaza un rand soft-sters. E nevoie de un MERGE ... WHEN MATCHED THEN UPDATE SET STERS = 0, DATAORA = ..., ID_UTIL = ..., TVA_INCASARE = ..., SERIE_ACT = ..., NRACT = ..., DATAACT = ..., DATAIREG = ..., ID_CTR = ..., ID_SET = ... pe langa WHEN NOT MATCHED THEN INSERT (cazul normal, ID_FACT nou din secventa).
4. Succesiunea corecta, in aceeasi tranzactie (deja planificata in S9 la nivel de VFP — vezi plan_13...md:1713-1719, mutarea stergerii in tranzactia deschisa de scriere): sterge documentul vechi (soft-delete, ca azi) -> seteaza variabila de la punctul 2 cu ID_FACT-ul citit inainte de stergere -> scrie documentul nou prin drumul obisnuit (ACT_TEMP cu ID_FACT = -1 ca de obicei, dar acum grupul respectiv va primi ID_FACT-ul fortat in loc de unul nou) -> commit doar dupa ce ambele operatii au avut succes; orice eroare -> rollback total, documentul vechi ramane intact.

• NU (fara aceste conditii): INSERT INTO DOCUMENTE cu ID_DOC reutilizat, cat timp randul vechi e inca prezent cu STERS=1, arunca ORA-00001 pe PK_DOCUMENTE — asta e dovada, nu presupunere (B.5 + B.4).

C.8 — Suprafata de risc pentru restul suitei

• ~25-30 cai de apel trebuie sa ramana neafectate: toate copiile COMUN\programe\ oscrie_in_fisiere.prg din fiecare produs ROA (listate in A.2), plus cele 3 variante care apeleaza SCRIE_IN_ACT direct. Toate trec prin acelasi punct final: SET_IDFACT(V_GCS) in PACK_CONTAFIN.pck:3037.
• Garantia structurala propusa: variabila de pachet noua, default NULL/inert, citita doar in interiorul corpului activ al lui SET_IDFACT (nu in semnatura, nu in vreun parametru propagat de apelanti); se seteaza explicit doar de codul de regenerare din ROAFACTURARE, chiar inainte de a incepe scrierea documentului reemis, si se consuma/reseteaza la prima citire (fie in SET_IDFACT, fie la finalul tranzactiei, ca sa nu "scurgi" valoarea catre urmatoarea scriere neinrudita din aceeasi sesiune Oracle — relevant daca goExecutor/conexiunea e reutilizata intre operatii ale aceluiasi utilizator in acelasi produs). Cu default inert si citire localizata strict in corpul lui SET_IDFACT, toate celelalte ~25-30 cai raman byte-for-byte identice cu azi — nu e nevoie sa se verifice fiecare apelant individual, garantia e la sursa (variabila neinitializata = comportament vechi).
• Riscul real nu e in SET_IDFACT, ci in DOCUMENTE. Schimbarea INSERT->MERGE cu WHEN MATCHED la PACK_CONTAFIN.pck:796-817 e riscanta pentru toata suita in alt sens: WHEN MATCHED s-ar declansa doar cand ID_DOC (generat din secventa) coincide cu unul existent — ceea ce, pe drumul normal, nu se intampla niciodata (secventa e monoton crescatoare, nu se repeta), deci practic ramura noua e inerta pentru toti apelantii actuali si activa doar cand variabila de la C.8 a fost setata explicit. Totusi orice modificare la acest INSERT/MERGE e in cod comun apelat de toata suita si trebuie testata pe cel putin un ciclu normal de scriere (fara variabila fortata) in fiecare produs care scrie facturi/note, nu doar in ROAFACTURARE.

Ramas de verificat pe baza vie

• Structura curenta reala a tabelei DOCUMENTE (DDL-ul citat e dintr-un script vechi de "firma noua"; coloanele SERIE_ACT/NRACT/DATAACT/DATAIREG/ID_CTR/ID_SET/TVA_INCASARE folosite de INSERT-ul activ nu apar in acel DDL — probabil adaugate ulterior prin ALTER TABLE). De rulat pe baza vie: SELECT column_name, nullable FROM user_tab_columns WHERE table_name = 'DOCUMENTE' ORDER BY column_id; si SELECT constraint_name, constraint_type FROM user_constraints WHERE table_name = 'DOCUMENTE'; — sa se confirme ca PK_DOCUMENTE e inca activa si ca nu exista alta constrangere aparuta intre timp.
• Daca exista deja documente reale in productie unde DOCUMENTE.ID_DOC a fost, intr-un fel sau altul, reutilizat (ex. printr-o interventie manuala) — de verificat cu SELECT id_doc, count(*) FROM documente GROUP BY id_doc HAVING count(*) > 1; (ar trebui sa fie gol, dat fiind PK-ul, dar merita confirmat inaintea oricarei schimbari).
• Comportamentul exact al finalizeaza_stergere_nota/finalizeaza_modificare_nota (:8601+, nu au fost citate integral aici) fata de ID_FACT/ID_FACTD — relevante daca reemiterea schimba seria/numarul, nu doar continutul (cazul S9 "de baza" e cel mai simplu: acelasi NRACT/SERIE_ACT).
• Comportamentul lui EXECUTA_SCRIE_TVA/SCRIE_JC_2007 (mentionate la :8504-8540, cazul an < 2007 sau JC) fata de reutilizarea ID_FACT — nu au fost verificate in detaliu, doar SCRIE_JV_2007.
• Nu am putut testa efectiv (fara acces la baza vie) daca ORA-00001 e chiar eroarea ridicata de Oracle in acest scenariu exact — e o deductie directa din DDL (PK unic + INSERT simplu pe coloana respectiva), dar merita o rulare de proba pe o baza de test inainte de a proiecta solutia finala.