TS-BP Handbook

Acces intern. Introdu parola.

TS-BP Handbook — proces manual

Ghid pas cu pas pentru procesarea cererilor de privacy (CPPA · EDW · Epsilon). Material intern — nu distribui.

v1.0 Ultima publicare: 13.11.2026 🆕 Ce e nou

CPPA = cererea de ștergere/mascare a datelor unui client. Fluxul: verifici identitatea clientului (IRIS · Epsilon · Snowflake) → unmerge → CCPA + GDPR → validezi că e curat → maschezi BP-urile → închizi ticketul. Un CPPA generează mai târziu și ticket EDW (+ Epsilon) pe același email.

Termen (SLA) — 45 de zile: cele 3 tickete ale aceluiași email (CPPA + EDW + Epsilon) au un singur termen comun = data deschiderii ticketului CPPA + 45 de zile calendaristice. Toate trebuie închise până atunci. Urmărește cât mai e: ≤14 zile = atenție, ≤5 zile = urgent, sub 0 = termen depășit.

1 Deschide ticketul și citește clientul

Coadă
🔗 Deschide coada CPPA în ServiceNow — ticketele „Privacy Compliance - Customer data masking".
Ce faci
Deschizi ticketul (caută după număr TASK…). Notează emailul clientului și numele (first + last) din descriere.
Ce decizi
Emailul e cheia întregului flux — cu el cauți în toate celelalte sisteme.
1.1 Preia ticketul (la începerea lucrului):
  • Assigned to = Ion Mustafenco.
  • Status = Work in Progress.
  • Click pe Update (dreapta sus).
ServiceNow Catalog Task — Assigned to Ion Mustafenco, Status Work in Progress, Update
Preluare ticket: Assigned to = Ion Mustafenco, Status = Work in Progress → Update.

2 Caută clientul în IRIS

Întâi — caută emailul în ServiceNow: înainte să începi procesarea, iei emailul din ticket și îi dai search în ServiceNow → vezi toate ticketele care apar ca rezultat pe acel email.
  • Verifici dacă nu există tickete de unmerge, sau altă problemă legată de acest cont / email.
  • Dacă există un unmerge (sau altă problemă) → mai întâi te clarifici cu acel ticket (îl rezolvi / aștepți) și abia apoi treci la procesul CPPA.
ServiceNow — search după email, lista de Catalog Tasks (Campaign, EDW, historical, CMA/WCS)
ServiceNow: search după email → toate ticketele legate (Campaign / EDW / historical DB / CMA-WCS) — verifici dacă nu e vreun unmerge sau altă problemă înainte de CPPA.
Unde
Ce faci
Cauți emailul. Deschizi profilul clientului.
Ce vezi
uid (= CDP ID, îl folosești la unmerge și GDPR), loyalty id-uri (zloyid), zwcs (logon ids / emailuri de logare), eventual PLCC (card de credit). Plus numele.
Ce decizi
Verifici că numele din IRIS = numele din ticket. 0 rezultate = clientul nu e în IRIS.
Căsătorie / middle name: dacă numele nu se potrivește perfect, poate fi schimbare de nume după căsătorie sau middle name. Match pe first name + o parte din last name = ok (ex. „Andrew Place-O Hern" în ticket vs „Place-O Hern" în sistem).
zwcs same-person: dacă un logon id/zwcs e pe alt email, dar numele clientului apare în acel email (ex. Trevor Randall → trandall@…), e aceeași persoană → ok, continui.
PLCC activ → Dalton: dacă clientul are card PLCC (TSC credit card) activ, cererea NU se poate îndeplini — nu ștergi/maschezi nimic. Reasignezi ticketul la Dalton:
  • Assignment group = Customer Privacy Compliance.
  • Assigned to = Dalton Holladay.
  • Status = Open.
  • Scrii comentariul în Work notes (Internal) → apeși Post.
  • Apoi Update (salvezi reasignarea).
Q-TOK1 — verifică dacă PLCC e activ (rulezi cu token-urile PLCC din IRIS)
SELECT * FROM MKT_DB.STG_REPL_TALEND_ODS.CDP_CONSUMER
WHERE POS_TOKEN IN ('<token_plcc>')

Ce înseamnă: token-urile PLCC le iei din IRIS. ≥1 rând = card PLCC ACTIV → reasignezi la Dalton (vezi comentariul de mai jos). 0 rânduri = fără PLCC activ → continui fluxul normal.

Comentariu la reasignare — Work notes (Internal), apoi Post
customer have active tsc credit card and cannot fullfill ccpa request by design when active

Variantă (ca în screenshot) — poți include numărul cardului: customer have active tsc credit: "<credit card number>", and cannot fullfill ccpa request by design when active.

ServiceNow — reasignare la Customer Privacy Compliance / Dalton Holladay, Status Open, Work notes + Post
Reasignare PLCC: Assignment group = Customer Privacy Compliance, Assigned to = Dalton Holladay, Status = Open, comentariul în Work notes (Internal) → Post.

3 Verifică loyalty-ul și identitatea în Snowflake

Unde
Snowflake (client SQL)
Ce faci
Rulezi Q-LOY cu loyalty id-urile (loyid) din IRIS — confirmă că numele de pe loyalty = clientul.
Q-LOY — un sales record per loyid (rank=1)
SELECT * FROM (
  SELECT ROW_NUMBER() OVER(PARTITION BY loyid ORDER BY trandate,idnumber,fname,lname) AS tran_rnk, *
  FROM (
    SELECT trandate, loyid, fname, lname, adrs1, city, state, zip, email, phnum1, phnum2, idnumber
    FROM MKT_DB.STG_MARKETING.VW_ZSALES_HEADER
    WHERE loyid IN ('7700000000000001')
  ) a
) b
WHERE tran_rnk = 1
ORDER BY loyid
Exemplu rezultat
LOYIDFNAMELNAMEEMAILSTATEIDNUMBER
7700000000000001JOHNDOEJOHN.DOE@EXAMPLE.COMMI10000000001

Ce înseamnă: numele de pe loyalty = clientul din ticket → identitate confirmată. IDNUMBER = cheia ZWCS/POS (vezi unmerge).

Ce faci
Dacă IRIS arată token-uri PLCC, rulezi Q-TOK1 — trebuie 0 rânduri ca să poți procesa.
Q-TOK1 — token PLCC în CDP_CONSUMER (trebuie 0 rânduri)
SELECT * FROM MKT_DB.STG_REPL_TALEND_ODS.CDP_CONSUMER
WHERE POS_TOKEN IN ('<token>')

Ce înseamnă: 0 rânduri = fără PLCC activ → procesezi normal. ≥1 rând = card activ → Dalton (vezi regula de la pasul 2).

[Screenshot] Snowflake — rezultat Q-LOY

4 Verifică emailul în Epsilon

Unde
Snowflake + Epsilon admin
Ce faci
Rulezi căutarea Epsilon după email — vezi dacă emailul are profil(e) de loyalty.
Epsilon — profile după email (PROFILE_EXTRACT)
SELECT profile_id, card_number, first_name, last_name, email_addr, enrollment_status
FROM MKT_DB.STG_EPSILON.PROFILE_EXTRACT
WHERE LOWER(TRIM(email_addr)) = 'john.doe@example.com'
Exemplu rezultat
PROFILE_IDCARD_NUMBERFIRSTLASTEMAILSTATUS
11111111-…-5555555555557700000000000001HannahGareyjohn.doe@example.comA

Ce înseamnă: profile_id = ce se va trimite la ștergere în fluxul Epsilon. STATUS: A=activ, I=inactiv, D=șters. 0 rânduri = emailul nu mai e în Epsilon.

Mai multe loyalty pe emailuri diferite = același client: dacă găsești mai multe loyalty id care aparțin aceluiași client dar sunt pe emailuri diferite, atunci toate loyalty-urile trebuie trecute sub emailul din ticket. În Epsilon admin editezi fiecare profil și pui ca adresă de email emailul din ticket.
Emailuri „victim" (nu se pot edita): unele profile sunt de tip victim — pe astea NU le poți edita direct. În acel caz:
  • Găsești survivor profile-ul (profilul care a „supraviețuit") și verifici dacă aparține clientului din ticket.
  • Dacă survivor-ul aparține clientului din ticket → survivor-ul trebuie să aibă emailul din ticket.
  • Salvezi separat ambele loyalty id (survivor + victim) — o să-ți trebuiască mai târziu pentru ticketele Epsilon (ex. de pus ca +pid victim).
[Screenshot] Epsilon admin — profilul găsit după email

5 Unmerge (Unmerge Toolkit din IRIS)

Unde
IRIS → meniul stânga Toolkits → Unmerge Toolkit
5.1
Iei CDP ID-ul clientului din IRIS — Account Details → CDP ID (ex. 6164210560). Apoi click pe Unmerge Toolkit (meniul Toolkits, stânga).
IRIS — CDP ID + Unmerge Toolkit
IRIS: iei CDP ID din Account Details, apoi Toolkits → Unmerge Toolkit.
5.2
Creezi un fișier CSV cu un singur rând = CDP ID-ul (fără header) și-l salvezi ca unmerge1.csv.
Exemplu conținut unmerge1.csv
6047589403
5.3
Choose File → selectezi unmerge1.csv → apeși Upload User Data.
Unmerge Toolkit — Choose File + Upload User Data
Unmerge Toolkit: Choose File (unmerge1.csv) → Upload User Data.
Ce vezi
După upload apare un rezultat / confirmare (de forma File 'unmerge1_…csv' uploaded…; procesarea în backend poate dura).
Ce decizi
Pui rezultatul de după upload în comentariul ticketului din ServiceNow (dovada că unmerge-ul a fost trimis). Apoi continui.
Unmerge manual prin Zeta: dacă pentru cazul ăsta ai făcut deja unmerge manual prin Zeta (vezi scenariul 3 de la validare), atunci unmerge-ul prin Toolkit (pasul ăsta) NU mai trebuie făcut — e deja rezolvat.

6 CCPA + GDPR (împreună)

⏰ CCPA + GDPR SE FAC LA MINIM 24 DE ORE DUPĂ UNMERGE (pasul 5). NU în aceeași sesiune — unmerge-ul trebuie întâi procesat în backend; dacă faci CCPA+GDPR imediat, datele nu se curăță corect. Deci: unmerge azi → CCPA + GDPR mâine (sau mai târziu).
CCPA și GDPR se fac împreună, în același pas. CCPA curăță SAP CRM; GDPR curăță IRIS/Zeta (durabil). Unul fără celălalt lasă date.
De unde
Ambele toolkit-uri se deschid din IRIS → meniul stânga Toolkits → CCPA Delete Toolkit / GDPR Delete Toolkit.
IRIS — meniul Toolkits cu CCPA Delete Toolkit și GDPR Delete Toolkit
IRIS → Toolkits → CCPA Delete Toolkit și GDPR Delete Toolkit (comun pentru pasul 6a și 6b).
6a · CCPA
CCPA PROD Delete Toolkit (din IRIS → Toolkits → CCPA Delete Toolkit).
Ce faci
Creezi un fișier cppa1.csv cu emailul din ticket → Choose File → cppa1.csv → Upload into Toolkit. Maschează SAP CRM.
Exemplu conținut cppa1.csv
john.doe@example.com
Ce decizi
Pui rezultatul de după upload în comentariul ticketului (comentariul standard CCPA).
CCPA PROD Delete Toolkit — CCPA1.csv uploaded, Upload complete + From/To Date + Fetch Stats
CCPA PROD Delete Toolkit: Choose File (cppa1.csv) → Upload into Toolkit → „Upload complete"; apoi pui From/To Date → Fetch Stats.
6b · GDPR
GDPR PROD Delete Toolkit (din IRIS → Toolkits → GDPR Delete Toolkit).
Ce faci
Iei CDP ID-ul LIVE din IRIS (re-caută emailul acum). În câmpul „Enter CDP User ID(s)" pui CDP ID-ul direct (nu fișier; mai multe = separate prin virgulă) → Upload into Toolkit.
Ce vezi
Apoi Fetch Stats (cu interval de date) → confirmi Verify_Delete_CDP = Y (jobul rulează zilnic, nu e instant).
GDPR NU se menționează în ticket. Ștergerea GDPR se face, dar în comentariul oficial ServiceNow scrii doar partea CCPA standard. Fără notă de GDPR.
CDP ID ≠ uid vechi: profilul se re-materializează — ia mereu CDP ID-ul LIVE din IRIS înainte de delete, nu cel notat la pasul 2.
GDPR PROD Delete Toolkit — Enter CDP User ID(s), Success file uploaded + From/To Date + Fetch Stats
GDPR PROD Delete Toolkit: Enter CDP User ID(s) (direct, separate prin virgulă) → Upload into Toolkit → „Success: File … uploaded successfully"; apoi pui From/To Date → Fetch Stats → Verify_Delete_CDP = Y.
Fetch Stats = ce s-a încărcat recent (pe interval de date): după upload, pui From Date / To Date și apeși Fetch Stats — îți arată ce a fost încărcat în acel interval (CCPA / GDPR), ca să confirmi că upload-ul tău a intrat și să citești statusul (la GDPR: Verify_Delete_CDP = Y). Pune intervalul care acoperă ziua în care ai făcut upload-ul.

7 Validare — clientul e curat (IRIS · CRM Search · BI Team)

⏰ VALIDAREA SE FACE LA MINIM 24 DE ORE DUPĂ CCPA (mascare + cleanse). NU în aceeași zi — datele au nevoie de timp să se proceseze în backend. Flux termen: unmerge → (24h) → CCPA + GDPR → (24h) → validare. Dacă validezi mai devreme, rezultatele pot fi false.
IRIS
Cauți emailul (Customer Search) → No rows / 0 rezultate. În plus, verifici fiecare BP din ticket în IRIS să nu mai fie prezent — caută BP-ul și cu 0, 00, 000 în față (uneori ID-ul e stocat cu zerouri în față), ca să fii sigur că nu apare sub nicio formă.
CRM Search
În SAP CRM, Identify Customer (rol Z_CSC_LOY), pui emailul în E-Mail Address → Search Account → trebuie „Result List : 0 Accounts Found".
BI Team
În SAP CRM, Search: Customers (rol BI), cauți după email → 0 rezultate.

Cum citești: 0 rezultate = curat; ≥1 = încă există date → investighează / repetă mascarea.

Identify Customer — Result List 0 Accounts Found
CRM Identify Customer → căutare după email → Result List : 0 Accounts Found.
BI Team Search Customers — email, Result List gol
BI Team Search: Customers → criteriu E-Mail → Result List gol (0 rezultate).
IRIS Customer Search — No rows
IRIS Customer Search → după email (sau BP, cu 0/00/000 în față) → No rows.
Scenariu 1 — BP încă apare în IRIS, contul e al userului din ticket: dacă la validare BP-ul mai apare în IRIS și contul aparține aceluiași client din ticket (numele/emailul confirmă) → datele nu s-au șters durabil. Reporni CPPA + GDPR pe acel client: reiei fluxul de la CCPA + GDPR Delete Toolkit (pasul 6) — CDP ID LIVE din IRIS → upload în ambele toolkit-uri (CCPA + GDPR, la pachet) → apoi re-validezi aici. (Profilul se poate re-materializa între timp, de aceea ia mereu CDP ID-ul live.)
Scenariu 2 — BP în IRIS cu divergențe, cont INACTIV: dacă BP-ul mai este în IRIS, contul are divergențe față de ticket (minore / medii / majore — ex. CHRIS ROBERGE în IRIS vs. Cooper Roberge în ticket), iar contul din IRIS e Inactive (cu sau fără email) → pui emailul din ticket pe contul din IRIS și reporni CPPA + GDPR.
  • Condiție obligatorie: contul IRIS trebuie să fie Account Status = Inactive. Dacă e activ → NU faci asta (e alt client / cont viu).
  • Pui emailul din ticket: în IRIS, tab-ul Communication → Add New Contact → Contact Method Email, Contact Value = emailul exact din ticket → salvezi. (Dacă emailul din ticket există deja pe cont, doar confirmi; dacă lipsește, îl adaugi — obligatoriu.)
  • Apoi reiei pasul 6 (CCPA + GDPR Delete Toolkit, CDP ID live) și re-validezi aici.
IRIS — cont Inactive, tab Communication, Add New Contact
IRIS: Account Status = Inactive → tab Communication → Add New Contact ca să pui emailul din ticket.
Ticket ServiceNow — FirstName/LastName/Email (divergență față de IRIS)
Ticketul: iei emailul exact (și numele) din descriere — aici Cooper Roberge, divergent de CHRIS ROBERGE din IRIS.
Scenariu 3 — BP în IRIS, contul e al ALTEI persoane și e ACTIV: dacă BP-ul mai e în IRIS, dar contul aparține exclusiv altei persoane (nu clientului din ticket) și e Active → NU reporni CPPA/GDPR și NU pui emailul din ticket pe el. E nevoie de investigare suplimentară + unmerge manual prin Zeta. (Pașii concreți pentru acest caz se definesc ulterior.)

8 Scoate BP-urile (Q1)

Unde
Snowflake
Ce faci
Rulezi Q1 cu emailul → lista BP-urilor (Business Partners) ale clientului.
Q1 — extract BPs după email
SELECT *
FROM MKT_DB.EDW.CUSTOMER_COMMUNICATION_CHANNEL
WHERE CUST_COMM_CHAN_METHOD = 'E01'
  AND UPPER(CUST_COMM_CHAN_EMAIL_ADDR) = UPPER('john.doe@example.com')
ORDER BY CUST_COMM_CHAN_END_DATE
Exemplu rezultat
SAP_BP_IDMETHODEMAIL_ADDREND_DATE
8006008501E01JOHN.DOE@EXAMPLE.COM9999-12-31
8006873009E01JOHN.DOE@EXAMPLE.COM9999-12-31

Ce înseamnă: fiecare SAP_BP_ID = un BP de mascat. END_DATE = 9999-12-31 = înregistrare activă.

Scoate doar BP-urile UNICE: Q1 poate întoarce multe rânduri (ex. 20+), dar multe sunt duplicate — același SAP_BP_ID apare de mai multe ori (activ + inactiv, pe perioade diferite). Iei doar valorile unice de SAP_BP_ID — acelea sunt BP-urile de mascat.

9 Închide ticketul CPPA + mesaj

Ce faci
Când validarea (pas 7) e curată, postezi mesajul de mai jos în ticket și închizi ticketul CPPA. (GDPR NU se menționează.)
Mesaj la close — CPPA (un singur BP)
<email> changes have been validated in CRM and IRIS/ZETA.
BP: <BP>
Mesaj la close — CPPA (mai multe BP-uri)
<email> changes have been validated in CRM and IRIS/ZETA.
BPS: <bp1>, <bp2>, <bp3>
De aici continuă pe ticketul EDW: extragerea BP-urilor, mascarea și verificarea (Q2/Q3) se fac în fluxul EDW → vezi tabul EDW.

EDW = scoaterea clientului din raportarea EDW. Pornești de la BP-urile clientului (același email ca la CPPA): le extragi (Q1), le maschezi în SAP CRM, apoi verifici (Q2/Q3) și închizi.
🔗 Deschide coada EDW în ServiceNow — ticketele „…completely removed from EDW reporting".

Termen (SLA) — 45 de zile: ticketul EDW împarte același termen cu CPPA și Epsilon ale aceluiași email: data deschiderii CPPA + 45 de zile calendaristice (nu de la deschiderea EDW). ≤14 zile = atenție, ≤5 zile = urgent, sub 0 = depășit.

1 Scoate BP-urile (Q1)

Unde
Snowflake
Ce faci
Rulezi Q1 cu emailul → lista BP-urilor (Business Partners) ale clientului.
Q1 — extract BPs după email
SELECT *
FROM MKT_DB.EDW.CUSTOMER_COMMUNICATION_CHANNEL
WHERE CUST_COMM_CHAN_METHOD = 'E01'
  AND UPPER(CUST_COMM_CHAN_EMAIL_ADDR) = UPPER('john.doe@example.com')
ORDER BY CUST_COMM_CHAN_END_DATE
Exemplu rezultat
SAP_BP_IDMETHODEMAIL_ADDREND_DATE
8006008501E01JOHN.DOE@EXAMPLE.COM9999-12-31
8006873009E01JOHN.DOE@EXAMPLE.COM9999-12-31

Ce înseamnă: fiecare SAP_BP_ID = un BP de mascat. END_DATE = 9999-12-31 = înregistrare activă.

Scoate doar BP-urile UNICE: Q1 poate întoarce multe rânduri (ex. 20+), dar multe sunt duplicate — același SAP_BP_ID apare de mai multe ori (activ + inactiv, pe perioade diferite). Iei doar valorile unice de SAP_BP_ID — acelea sunt BP-urile de mascat.

2 Maschează fiecare BP în SAP CRM

Unde
SAP CRM prin SAP Logon (în WM), rolul BI Team.

Mascarea se face prin SAP Logon, pe rolul de business ZTSCMKTPRO – BI Team. Pașii concreți:

  1. Intri pe rolul ZTSCMKTPRO – BI Team. La selecția rolului de business, alegi ZTSCMKTPRO - BI Team.
    Select business role — ZTSCMKTPRO BI Team
    Selectează rolul ZTSCMKTPRO - BI Team.
  2. Navighezi la Accounts. Din dropdown-ul Home (dreapta sus) → Accounts & Products; apoi în blocul Search → Accounts.
    Home dropdown → Accounts & Products
    Dropdown Home → Accounts & Products.
    Accounts & Products → Search → Accounts
    În Search → Accounts.
  3. Cauți BP-ul după Account ID. În Search: Customers, pui criteriul Account ID = BP-ID-ul (ex. 425288382) → Search. În Result List dai click pe nume → intri în profil.
    Search Customers — Account ID = BP-ID → Search
    Criteriu Account ID = BP-ID → Search.
    Result List — click pe nume pentru a deschide profilul
    Click pe nume (ex. JOHN DOE) → deschide profilul.
  4. Apeși Edit și maschezi datele. În profil, dreapta sus → Edit (pagina trece în modul editare). Apoi golești toate câmpurile de identitate și pui Last Name = DONOTUPDATE. La final profilul trebuie să arate DOAR Last Name = DONOTUPDATE (restul gol), ca în exemplu:
    • Golești: First Name, Middle Name, Search Term, Correspondence lang., Street/House Number, Postal Code/City, E-Mail.
    • Last Name = DONOTUPDATE.
    Profil — buton Edit
    Dreapta sus → Edit.
    Edit — Last Name DONOTUPDATE, restul gol (exemplu)
    Exemplu rezultat: Last Name = DONOTUPDATE, celelalte câmpuri golite.
    4.1 Scrolezi în jos la tabelul Communication Table → click pe Edit List (dreapta sus).
    Communication Table — Edit List
    În Communication Table → Edit List.
    4.2 Dai click pe un rând → apeși Delete (coșul, dreapta sus). Repeți până nu mai rămâne niciun item în tabel (atenție: poate fi mai mult de o pagină — vezi Back / 1 2 / Forward jos).
    Communication Table — selectează rând și Delete
    Selectezi rândul → Delete (coș), până golești tabelul.
    4.3 Când tabelul e gol, apeși Insert. La Communication Method alegi unul din cele 3 phone methods: Work Phone, Cell Phone sau Home Phone. În câmpul Phone pui 0000000000.
    Communication Table gol — Insert
    Tabel gol → Insert.
    Alege phone method + Phone = 0000000000
    Method = un phone method; Phone = 0000000000.
    Rezultat — Work Phone cu telefon mascat
    Exemplu rezultat: un singur rând (ex. Work Phone) cu telefon mascat.
    4.4 În pagină dai Ctrl+F și cauți do not — sunt 8 checkbox-uri „Do Not…" → le bifezi pe toate (sunt pe tabul Demographics):
    • Do Not Update - Name · Do Not Update - HH · Do Not Update - Addr · Do Not Contact Mail
    • Do Not Call Work · Do Not Call OTHER · Do Not Call HOME · Do Not Call CELL
    Do Not Update/Contact — 4 checkbox-uri
    Bifezi: Update-Name, Update-HH, Update-Addr, Contact Mail.
    Do Not Call — 4 checkbox-uri
    Bifezi: Call Work, Call OTHER, Call HOME, Call CELL.
    4.5 Apeși Save (jos-dreapta).
    Save-ul a reușit când butonul Save DISPARE. Dacă rămâne după click → nu s-a salvat: verifici cauza (jos-stânga apare o eroare, ex. „Enter a postal code") → o rezolvi și salvezi din nou.
    Butonul Save
    Save / Cancel (jos-dreapta).
    Eroare la save — Enter a postal code
    Dacă nu dispare: eroarea jos-stânga spune de ce (ex. „Enter a postal code").
  5. Cleanse — se face separat prin SAP Logon (SAP GUI desktop), în CRM PC1 (Production).
    5.1 Deschizi programul SAP Logon (de pe desktop).
    5.2 Din listă (Connections) alegi CRM PC1.
    5.3 Introduci credențialele: user <user> + parola → Enter.
    SAP Logon → CRM PC1 → login
    SAP Logon → CRM PC1 → login (user <user>). Atenție: e mediul PRODUCTION.
    5.4 În câmpul de comandă (sus-stânga) scrii sa38 → Enter.
    SAP Easy Access — okcode sa38
    Câmp comandă → sa38 → Enter.
    5.5 La Program scrii ZMC_switch_cleanse_status → apeși F8 (sau meniu Program → Execute).
    Program = ZMC_switch_cleanse_status
    Program = ZMC_switch_cleanse_status.
    Program → Execute (F8)
    F8 sau Program → Execute.
    5.6 În ecranul „Switch customer cleansing status": la Business Partner pui BP-ID-ul; scoți bifa de la Test Run; la Max number of dialogs pui 5. (Cleansing Status rămâne CLEANSED.)
    Cleanse — BP, Test Run off, Max dialogs 5
    BP-ID + Test Run debifat + Max dialogs = 5.
    5.7 Apeși F9 (sau meniu Program → Execute in Background) — cleanse-ul rulează ca job în background.
    Program → Execute in Background (F9)
    F9 / Program → Execute in Background.
    5.8 Apare dialogul Background Print Parameters → click pe bifa verde (confirm). Jobul de cleanse e trimis.
    Background Print Parameters — confirmă (bifa verde)
    Background Print Parameters → bifa verde (confirm).
    5.9 Apare dialogul Start Time → click pe Immediate (apoi Check / salvează) — jobul pornește imediat.
    Start Time — Immediate
    Start Time → Immediate.
    5.10 Cu Immediate Start bifat, apeși butonul Save (dischetă, lângă Check) — jobul de cleanse e programat și pornește imediat.
    Start Time — Save (dischetă)
    Immediate Start → Save (dischetă).
Unlock BP (după situație) — lock agățat în SAP: dacă la deschiderea/editarea BP-ului SAP zice „being processed by user…", înseamnă că o sesiune anterioară (mask/WebGUI) nu s-a închis curat și a lăsat un lock agățat pe partener. Îl ștergi din SM12 (pașii de mai jos). ⚠️ Ștergi DOAR lock-ul tău — un lock pe alt user = chiar editează cineva acum, nu-l atinge.
Înainte de unlock: închide întâi tab-ul BP-ului respectiv din CRM (fereastra/sesiunea unde era deschis partenerul). Dacă-l lași deschis, lock-ul se pune la loc imediat după ștergere (sau rămâne inconsistent). Întâi închizi tab-ul BP-ului, apoi faci pașii de mai jos.
U.1 În SAP Logon, în câmpul de comandă (okcode) scrii sm12 → Enter.
SAP Easy Access — okcode sm12
SAP Logon: în câmpul de comandă scrii sm12 → Enter.
U.2 În ecranul Select Lock Entries, la Table name scrii BUT000 → Enter. (User Name e deja userul tău; lași Client-ul cum e.)
Select Lock Entries — Table name BUT000, User Name userul tău
Select Lock Entries: Table name = BUT000, User Name = userul tău → Enter.
U.3 Execute (F8) → se afișează Lock Entry List.
U.4 Vezi un rând cu lock-ul tău: User Name = userul tău, Table = BUT000, iar Lock Argument = identificatorul blocat (ex. 1000434502249). Îl selectezi (jos scrie „Selected Lock Entries: 1").
U.5 Apeși pe iconul Delete (coș de gunoi) din bara de sus (echivalent cu Lock Entry → Delete).
Lock Entry List — rând IMUSTAFENCO/BUT000 selectat + icon Delete
Lock Entry List: selectezi rândul cu lock-ul tău (Lock Argument = identificatorul blocat) → apeși iconul Delete (coș).
U.6 La dialogul „Delete lock entry?" apeși Yes.
Delete lock entry? — Yes/No/Cancel
Dialog „Delete lock entry?" → Yes.
U.7 Dacă apare mesajul „The lock entry has been manually deleted (transaction SM12)." → e OK, lock-ul e șters. Închizi fereastra. Acum poți redeschide/edita BP-ul normal.
Confirmare: mesajul „The lock entry has been manually deleted (transaction SM12)." = deblocarea a reușit. Dacă apare, îl închizi — e tot OK.
Performance Assistant — The lock entry has been manually deleted (transaction SM12)
Mesaj „The lock entry has been manually deleted (transaction SM12)." → deblocarea a reușit, închizi fereastra.
BP nu apare în BI search: BP inexistent / deja curat = reziduu istoric → skip (nimic de mascat, mai ales dacă Q2 e valid). Dacă Q2 e invalid dar BP-ul tot nu se găsește în BI Team (nu-l poți masca) → „accept reziduu" și la close folosești mesajul dedicat de la pasul 4 („BP negăsit în BI Team / reziduu").
Mesaj după mascare (postat în ticketul EDW)
Data processed for: <bp1>, <bp2>.
Waiting 48-72Hrs for data to process and proceed with validation

După mascare + cleanse postezi acest mesaj și aștepți 48–72h până verifici (pas 3). Dacă remaschezi mai târziu, folosești varianta „Data processed again for: …".

3 Verifică mascarea (BI Team + Q2 + Q3)

⏰ VERIFICAREA SE FACE LA MINIM 24 DE ORE DUPĂ MASCARE + CLEANSE. NU în aceeași zi — datele au nevoie de timp să se proceseze (de-aia mesajul „Waiting 48-72Hrs…"). Dacă verifici prea devreme, BI Team / Q2 / Q3 pot arăta fals nemascat.
Unde
SAP CRM (BI Team) + Snowflake
BI Team
Mai întâi re-verifici în BI Team: cauți BP-ul și deschizi profilul, și confirmi că:
  • Name = DONOTUPDATE (first/middle/search term goale);
  • Phone = 0000000000 sau deloc (fără telefon);
  • fără alte date — fără adresă, fără email, fără alte câmpuri completate.
Dacă ceva din astea nu-i curat → mai maschezi odată (vezi pas 2) înainte să treci la Q2/Q3.
BI Team — rezultat bun: DONOTUPDATE + telefon mascat, fără alte date
Exemplu rezultat BUN în BI Team: Name = DONOTUPDATE, Phone = +1 (000000000), fără street/city/region/email.
Email = 0
Apoi cauți emailul și confirmi că nu mai apare nimic: în Identify Customer (rol Z_CSC_LOY) → Result List : 0 Accounts Found; și în BI Team Search: Customers după email → 0 rezultate.
IRIS
Aceeași validare ca la CPPA: în IRIS Customer Search verifici fiecare BP din ticket să nu fie prezent — caută și cu 0/00/000 în față → No rows.
IRIS Customer Search — No rows
IRIS Customer Search → după email/BP (cu 0/00/000 în față) → No rows.
Identify Customer — Result List 0 Accounts Found
CRM Identify Customer → căutare după email → Result List : 0 Accounts Found.
BI Team Search Customers — email, Result List gol
BI Team Search: Customers → criteriu E-Mail → Result List gol (0 rezultate).
⚠️ BP de tip GROUP — tratament special: unele BP-uri sunt de tip group („GROUP CUSTOMER"). Arată și se comportă diferit:
  • View diferit: profilul e GROUP CUSTOMER — Account Details fără Communication Table. Telefonul se adaugă în secțiunea separată Address Independent Communication Numbers (nu în tabelul obișnuit).
  • Poate să NU se mascheze ca un BP normal, iar în Snowflake rezultatul (Q2) poate fi diferit — poate rămâne cu E01/D01 etc. Nu-l forța la remask la nesfârșit.
BI Team — GROUP CUSTOMER în result list
BI Team — un BP group apare ca GROUP CUSTOMER (ex. 228162176, DONOTUPDATE).
GROUP CUSTOMER — view diferit, Cust Cleanse Status Cleansed
Profil GROUP CUSTOMER — layout diferit; Cust Cleanse Status = Cleansed, fără Communication Table.
Address Independent Communication Numbers
Telefonul stă în Address Independent Communication Numbers (aici „No result found").
Mesaj de close — EDW pentru BP-uri GROUP (paragraf adăugat)
Those BPs: <group_bp1>, <group_bp2> were masked and cleansed in CRM.
There is no flow of updates to flow from CRM to EDW for these kinds of business partners
Validare BI Team la group: la aceste BP-uri telefonul 000000000 poate să dispară din view — e OK. Principalul e ca BP-ul să fie curat în query (Q2/Q3), nu neapărat să aibă telefonul mascat vizibil în BI Team.
Q2
Per BP — verifici comunicările viitoare (end_date > azi). Rulezi pentru fiecare BP.
Q2 — validate BP
SELECT *
FROM MKT_DB.EDW.CUSTOMER_COMMUNICATION_CHANNEL
WHERE SAP_BP_ID = '8006008501'
  AND CUST_COMM_CHAN_END_DATE > CURRENT_DATE

Regula Q2: BP-ul e VALID dacă (a) 0 rânduri, SAU (b) toate rândurile au METHOD ∈ {P01,P02,P03} cu telefon mascat (gol / 0000000000). Orice E01 (email), telefon real, sau alt cod activ = INVALID.

✅ VALID · exemplul 1 — 0 rânduri (fără comunicări viitoare)
SAP_BP_IDMETHODPHONE_NOEND_DATE
(niciun rând)

Nimic de trimis clientului → curat.

✅ VALID · exemplul 2 — doar P01/P02/P03 cu telefon mascat
SAP_BP_IDMETHODPHONE_NOEND_DATE
8006008501P0100000000009999-12-31
8006008501P0200000000009999-12-31
8006008501P0300000000009999-12-31

Toate P01/P02/P03 + telefon 0000000000 → mascat corect.

🔴 INVALID · exemplul 1 — email E01 încă activ
SAP_BP_IDMETHODEMAIL_ADDREND_DATE
8006008501E01JOHN.DOE@EXAMPLE.COM9999-12-31

Emailul (E01) e încă activ → mascarea n-a prins / BP resuscitat → remask + investigare.

🔴 INVALID · exemplul 2 — telefon real
SAP_BP_IDMETHODPHONE_NOEND_DATE
8006008501P0155512345679999-12-31

METHOD e P01, dar telefonul e real (nu 0000000000) → încă e contactabil → remask.

Q3
La nivel de email — emailul nu mai apare cu E01 activ pe niciun BP.
Q3 — email clean
SELECT *
FROM MKT_DB.EDW.CUSTOMER_COMMUNICATION_CHANNEL
WHERE CUST_COMM_CHAN_METHOD = 'E01'
  AND UPPER(CUST_COMM_CHAN_EMAIL_ADDR) = UPPER('john.doe@example.com')
  AND CUST_COMM_CHAN_END_DATE > CURRENT_DATE
✅ CURAT — 0 rânduri
SAP_BP_IDMETHODEMAIL_ADDREND_DATE
(niciun rând)

Emailul nu mai apare activ nicăieri → curat, scopul atins.

🔴 NECURAT — leftover (emailul încă activ pe un BP)
SAP_BP_IDMETHODEMAIL_ADDREND_DATE
8006873009E01JOHN.DOE@EXAMPLE.COM9999-12-31

≥1 rând = BP-urile din rezultat (ex. 8006873009) încă au emailul activ (leftover) → acele BP se remaschează.

Dacă la validare găsești ceva NEMASCAT: remaschezi BP-ul (vezi pas 2) și lași în ticket comentariul de mai jos; apoi aștepți 48–72h și reiei validarea.
Comentariu la re-mask (Data processed again)
Data processed again for: <bp1>, <bp2>.
Waiting 48-72Hrs for data to process and proceed with validation
Reziduu: dacă Q2 rămâne INVALID deși mascarea a reușit (BP apare mascat în BI Team, dar Q2 tot blocat), repeți mascarea și investighezi — e cazul în care pipeline-ul resuscită un email vechi pe BP. Dacă BP-ul nu apare deloc în BI search și Q2 e valid → skip (reziduu istoric).

4 Închide ticketul EDW + mesaj

Ce faci
Când BP-urile sunt mascate și verificarea (Q2/Q3) e curată, postezi mesajul de close și închizi ticketul EDW.
Mesaj la close — EDW (validat)
Data validated for: <bp1>, <bp2>
Mesaj la close — EDW cu BP-uri de tip GROUP
Data validated for: <bp1>, <bp2>

Those BPs: <group_bp1>, <group_bp2> were masked and cleansed in CRM.
There is no flow of updates to flow from CRM to EDW for these kinds of business partners

Dacă ai BP-uri de tip group (fără flux CRM→EDW), adaugi al doilea paragraf cu acele BP-uri.

Mesaj la close — EDW, BP negăsit în BI Team (nu se poate masca / reziduu, Q2 invalid)
Data validated for: <bp1>, <bp2>

BP <bp> is not searchable in the BI Team / CRM — there is no record to mask (historical residue).
There is no flow of updates from CRM to EDW for this business partner, so the remaining data cannot be re-identified as this customer.

Când: un BP are Q2 invalid dar în BI Team nu se găsește (inexistent / deja curat = reziduu istoric) → nu-l poți masca. În soft = „accept reziduu EDW" (sare Q2/Q3, IRIS rămâne impus). Adaugi al doilea paragraf cu acel BP, înlocuind <bp> cu numărul lui.

Epsilon = scoaterea clientului din baza Epsilon (Campaign database / loyalty). Verifici emailul în Epsilon → iei profile_id → îl trimiți la ștergere printr-un Loyalty delete request → lași comentariul în ticket → confirmi ștergerea.
🔗 Deschide coada Epsilon în ServiceNow — ticketele „…completely removed from Campaign database".

Termen (SLA) — 45 de zile: ticketul Epsilon împarte același termen cu CPPA și EDW ale aceluiași email: data deschiderii CPPA + 45 de zile calendaristice (nu de la deschiderea Epsilon). ≤14 zile = atenție, ≤5 zile = urgent, sub 0 = depășit.

1 Deschide ticketul și citește emailul

Unde
ServiceNow (coada Epsilon de mai sus)
Ce faci
Deschizi ticketul, notezi emailul clientului.

2 Verifică emailul în Epsilon (profile_id)

Unde
Snowflake
Ce faci
Rulezi query-ul care caută emailul în Epsilon (PROFILE_EXTRACT) → profile_id-urile.
Epsilon — profile după email
SELECT profile_id, card_number, first_name, last_name, email_addr, enrollment_status
FROM MKT_DB.STG_EPSILON.PROFILE_EXTRACT
WHERE LOWER(TRIM(email_addr)) = 'john.doe@example.com'
Exemplu rezultat
PROFILE_IDCARD_NUMBERFIRST_NAMELAST_NAMEEMAIL_ADDRENROLLMENT_STATUS
11111111-2222-3333-4444-5555555555557700000000000001JOHNDOEjohn.doe@example.comA

Ce înseamnă: PROFILE_ID = ce trimiți la ștergere. ENROLLMENT_STATUS: A=activ, I=inactiv, D=șters. 0 rânduri = emailul nu mai e în Epsilon → scopul atins (ticketul se închide, fără pid).

Alternativ
Poți lua profile_id și direct din Epsilon admin: deschizi profilul clientului, iar în URL, după profileId=, e chiar profile_id-ul.
Epsilon admin — profile_id în URL după profileId=
Epsilon admin: deschizi profilul → în URL, după profileId=, e profile_id-ul.

3 Creează Loyalty delete request

Unde
Epsilon support (support.epsilon.com)
  1. Te loghezi pe support.epsilon.com — introduci emailul tău → Login.
    Epsilon support — login cu email
    Introduci emailul → Login.
  2. Sus, alegi Request Something.
    Epsilon — Request Something
    Meniu sus → Request Something.
  3. Din Product Catalog alegi Loyalty.
    Product Catalog — Loyalty
    Product Catalog → Loyalty.
  4. Alegi Loyalty General Request.
    Loyalty — Loyalty General Request
    Popular requests → Loyalty General Request.
  5. Completezi forma și dai Submit:
    • Urgency: 3 - Medium
    • Title: CCPA Requests : Time sensitive
    • Description: „Please remove the following profiles from the Epsilon database:" + profile_id-urile (unul pe rând).
    Description (în formă)
    Please remove the following profiles from the Epsilon database:
    
    <profile_id_1>
    
    <profile_id_2>
    Loyalty General Request — formă completată + Submit
    Formă: Urgency 3-Medium, Title „CCPA Requests : Time sensitive", Description cu profile_id-uri → Submit.
Ce vezi
După Submit primești un număr de caz CS… (CS number).
Se trimite în BATCH: de obicei nu trimiți la fiecare ticket separat — aduni ticketele eligibile care au profile_id și trimiți un singur request pe toate, când ai o cantitate (ex. ~15) sau după un interval (ex. ~10 zile) / când se apropie SLA-ul.

4 Comentariu în ticket

Ce faci
Pui în fiecare ticket (al profile_id-urilor din request) comentariul cu CS-ul:
Comentariu Loyalty delete (Epsilon)
Loyalty deletion request <CS> created for removal of profile_id <pid1>, <pid2> from the Epsilon database.

5 Loyalty „victim" / +pid

Ce faci
Profile-urile de tip victim (de la CPPA — survivor/victim, pas 4) le incluzi aici: loyalty-ul victim salvat se trimite și el la ștergere ca +pid, chiar dacă nu putea fi editat. (De-aia la CPPA salvezi ambele loyalty id separat.)

6 Verifică ștergerea

Unde
Snowflake + Epsilon admin
Ce faci
Re-rulezi query-ul de la pas 2. Șters = enrollment_status = D (Deleted) + email gol, sau 0 rânduri. (Ștergerea nu e instant — job Epsilon.)
Ce vezi
Confirmi că în Epsilon nu mai există rezultat nici după email, nici după loyalty (card number / profile): căutarea întoarce 0 rezultate (sau status D). Atunci clientul e scos din Epsilon.
Query de verificare (Snowflake) — același ca la pas 2
SELECT profile_id, card_number, first_name, last_name, email_addr, enrollment_status
FROM MKT_DB.STG_EPSILON.PROFILE_EXTRACT
WHERE LOWER(TRIM(email_addr)) = 'john.doe@example.com'
✅ VALID — exemplul 1: 0 rânduri
PROFILE_IDCARD_NUMBEREMAIL_ADDRENROLLMENT_STATUS
(niciun rând)

Emailul nu mai apare în Epsilon → șters.

✅ VALID — exemplul 2: status D (șters)
PROFILE_IDCARD_NUMBEREMAIL_ADDRENROLLMENT_STATUS
11111111-2222-3333-4444-5555555555557700000000000001(gol)D

ENROLLMENT_STATUS = D (Deleted) + email gol → șters.

🔴 ÎNCĂ NEVALID: status A, email prezent
PROFILE_IDCARD_NUMBEREMAIL_ADDRENROLLMENT_STATUS
11111111-2222-3333-4444-5555555555557700000000000001john.doe@example.comA

Încă activ cu email → ștergerea nu a fost procesată încă (job Epsilon); mai aștepți / verifici CS-ul.

Alternativ
Poți verifica și în Epsilon admin: Search By Profile → pui emailul (sau card number) → Search → tabelul e gol (0 items).
Epsilon admin — Search by email, 0 items
Epsilon admin: Search By Profile → email → 0 items (niciun rezultat).

7 Confirmă în Loyalty General Request (support Epsilon)

Unde
Epsilon support → ticketul Loyalty General Request creat la pasul 3 (CS-ul, ex. CS0709578)
Ce faci
După ce ai confirmat la pasul 6 că profile_id-urile nu mai apar în Epsilon (0 rezultate / status D), intri în ticketul Loyalty General Request și confirmi acolo că au dispărut din Epsilon.
Ce vezi
Support-ul Loyalty (ex. David Daniel) scrie: „The CCPA request has been completed, please verify and let us know." → asta e semnalul să verifici și să confirmi.
Răspuns în ticket — Additional comments → Send
validated

Când: doar după ce tu ai verificat în Epsilon (pasul 6) că profilurile chiar s-au șters. Scrii validated în Type your message here… → Send. Abia apoi închizi ticketul ServiceNow (pasul 8).

Loyalty General Request — support confirmă 'CCPA request completed, please verify', iar tu răspunzi 'validated'
Loyalty General Request: support scrie „CCPA request has been completed, please verify…" → tu răspunzi validated (după ce ai confirmat ștergerea în Epsilon).

8 Închide ticketul

Ce faci
Ticketele fără profile_id (emailul nu-i în Epsilon) → se închid (nimic de trimis). Cele cu request trimis → se închid după confirmarea ștergerii.
Comentariu la close — Epsilon (emailul nu mai e în Epsilon)
The email <email> is not searchable in epsilon.

Când: emailul nu mai întoarce rezultat în Epsilon (0 rânduri / status D la pasul 6). Înlocuiești <email> cu emailul din ticket.

🆕 Ce e nou — actualizările handbook-ului, cea mai recentă sus. Dă click pe un punct ca să sari direct la secțiunea modificată (se evidențiază câteva secunde).

v1.0

13.11.2026 — prima versiune cu numerotare + changelog