Agency Flow — Ghid rapid

01

Cum aleg billing type-ul?

O singură întrebare desparte totul: cine face munca? Apoi câte o întrebare pe ramură.

LABOR Echipa noastră face munca

Fără furnizor. Întrebarea: cum se transformă orele în factură?

A1Factura e o sumă fixă lunarăorele contează doar pentru profit, nu pentru factură A2Fiecare oră se facturează, la o rată unicăo rată pe serviciu, nu per persoană BOre incluse + tarif de depășiredouă benzi, aplicate marginal, prag în ore

SUPPLIER Un furnizor face munca

Fără muncă internă. Întrebarea: cum arată costul și adaosul?

CCost fix, fără adaospass-through, profit 0 — legitim DCost fix + fee fixprofitul = fee-ul; clientul vede o singură sumă ECost variabil, fără adaosspecialistul introduce costul lunar F1Pe livrabile, furnizori diferițilinii per livrabil, două roluri, fee per linie F2Pe orele furnizoruluicost/h + fee/h fixate, orele intră lunar F3Markup % peste cost variabilprocent fixat, cost lunar PLPlatformă media cu rebate + feehibridul: supplier + tasks; două bucket-uri de profit

Regula de aur: un serviciu = exact un billing type, și e labor sau supplier — niciodată ambele. Singura excepție e Platform. Dacă un client are și ore de echipă și un furnizor, acelea sunt două servicii pe același asset.

02

Toate tipurile, umăr la umăr

Fiecare rând e un link către fluxul complet.

Tip	Setup (fix)	Intră lunar	Cine, lunar	Nașterea perioadei	Cost line	Factura client	Profit
A1 Fixed fee	fixed_amount	nimic (pontaje pt. profit)	echipa (ore)	ready	—	fixed_amount	invoice − labour
A2 Hourly flat	billed_rate	ore din pontaje	echipa (ore)	cost_entry → ready la închidere	—	rate × Σ ore	invoice − labour
B Hourly tiered	cap · base · over	ore din pontaje	echipa (ore)	cost_entry → ready la închidere	—	≤cap@base + rest@over	invoice − labour
C Fixed cost	supplier_cost	nimic	nimeni	ready	1 / lună, de engine	= cost	0 (pass-through)
D Fixed + fee	supplier_cost · fee	nimic	nimeni	ready	1 / lună, de engine	cost + fee	fee (fee_profit)
E Variable	— (fără tabel)	input_supplier_cost	specialist	cost_entry → ready la input	1 / lună, de engine	= cost	0 (pass-through)
F1 Per deliverable	— (fără tabel, fără supplier)	linii: supplier·qty·cost·fee	specialist + finance	cost_entry → awaiting_fee → ready per linie	N / lună, de OM	Σ qty×(cost+fee)	Σ qty×fee (fee_profit)
F2 Cost/h + fee/h	cost/h · fee/h	input_supplier_hours	specialist	cost_entry → ready la input	1 / lună, de engine	(cost/h+fee/h)×ore	fee/h × ore (fee_profit)
F3 % of cost	fee_pct	input_supplier_cost	specialist	cost_entry → ready la input	1 / lună, de engine	cost × (1+pct)	pct × cost (fee_profit)
PL Platform	platform_pct · client_pct	input_amount_spend + pontaje	specialist + echipa	cost_entry → ready la input	1 / lună, de engine (netul)	spend × (1+client_pct)	rebate (direct) + fee−labour (recovery_net)

03

Stările și înghețarea — o singură dată, pentru toți

Starea răspunde la o singură întrebare: câtă încredere ai în cifrele lunii? Nu „câtă muncă s-a depus".

cost_entry→ awaiting_fee→ ready→ invoiced

cost_entry = cifrele se adună / se așteaptă un om · awaiting_fee = doar F1, finance n-a pus fee-ul · ready = facturabilele au înghețat (ready_at) · invoiced = totul a înghețat (invoiced_at), corecții doar prin storno.

Înghețarea în două faze

la ready: factura clientului, costul de furnizor, bucket-urile de fee
la invoiced: labour-ul (pontajele întârzie mereu) și derivatele lui
între ele, labour-ul curge liber — de-asta există două timestamp-uri

Resetările

editezi un cost → linia/perioada cade înapoi în cost_entry
schimbi setup-ul → se recalculează doar lunile ne-înghețate
după invoiced → nimic nu se editează; doar storno

Cine are voie la ce

specialist: costuri (linii F1, cost E/F3, ore F2, spend PL)
finance/ops: fee-ul F1 per linie + send back + facturare
clientul: vede mereu o singură sumă — niciodată split-ul cost/fee

04

Glosarul banilor — vocabularul canonic

Orice raport, orice pagină, orice discuție folosește exact acești termeni (spec §1.12.1).

AR: Accounts Receivable — facturile pe care le emitem noi clientului (ce încasăm). Materializată în client_invoice.
AP: Accounts Payable — facturile pe care le primim de la furnizor și le înregistrăm (ce plătim). Ancorate în service_cost_line.
client_invoice: ce facturăm clientului. Singura cifră pe care o vede el.
supplier_cost: banii care ies real către furnizor. 0 la tipurile labor. La Platform: spend − rebate.
labour_cost: Σ ore × cost/h per angajat (din payroll, cu rata efectivă la data pontajului). 0 la C–F.
gross_profit: client_invoice − supplier_cost — spread-ul de cash, înainte de muncă. Calculat de DB.
net_profit: gross − labour — cifra-titlu a profitabilității. Calculată de DB.
direct_profit: bucket: rebate-ul de platformă — profit care nu se erodează cu orele.
fee_profit: bucket: fee-urile D/F1/F2/F3 — marjă curată, fără muncă în spate.
labour_recovery: bucket: fee-ul de Platform (client_pct × spend) — banii meniți să plătească echipa.
recovery_net: labour_recovery − labour_cost — a ajuns fee-ul? KPI-ul de renegociere. Calculat de DB.
amount_spend: cifra-antet la Platform. Nu e cost, nu e venit — doar trece prin factură.
margin %: doar un ratio de afișare = gross ÷ invoice. „Marja" nu e un substantiv de bani în sistem — nu se stochează, nu se adună.

05

Cazul special: bugetul lunar al clientului

Nu e un billing type. Un billing type spune cum se naște o cifră dintr-un serviciu. Bugetul spune ce sumă finală pleacă pe factură, peste tot ce calculează serviciile — de-aia e un overlay la nivel de client — un enum brand.billing_mode (per_service / budget), cu brand.budget + brand.budget_currency ca parametri (serviciile clientului-buget moștenesc moneda). Cazul G, spec §1.11b.

Ce se schimbă, de fapt: o singură cifră — ce apare pe factură. Serviciile clientului rulează absolut normal (perioade, stări, snapshot-uri), doar că devin actuals — referință, nu sursa facturii. Nimic din schema serviciilor nu se atinge; doar strategia de asamblare a facturii, aleasă de billing_mode, ia altă cifră. billing_mode e o strategie de nivel-client — distinctă de billing type-ul (per-serviciu), două niveluri diferite.

Cheia: pentru un client cu buget, sistemul ține două cifre în paralel pentru aceeași lună.

Cifra	Ce e	De unde vine	O vede clientul?
invoiced ce facturezi	bugetul, o singură linie fixă — nu suma serviciilor	brand.budget (mode=budget)	da — singura cifră
delivered_value ce ai livrat	valoarea reală a serviciilor, calculată normal ca actuals	Σ snapshot_client_amount	nu — doar intern

Exemplu concret — client cu buget 5.000 €/lună, trei servicii care rulează normal ca actuals:

Serviciu	Tip	delivered_value	supplier_cost	labour_cost
SEO Tehnic	A2 hourly flat	1.800 €	0	900 €
Google Ads	D fixed + fee	1.500 €	1.200 €	0
Content	F1 per deliverable	900 €	700 €	0
Σ (actuals)	—	4.200 €	1.900 €	900 €

Ce se întâmplă cu cifrele:
• Factura clientului = 5.000 € (bugetul, o linie) — nu 4.200 €. Clientul nu vede defalcarea.
• Variația de scop = 5.000 − 4.200 = +800 € → under-serviced: ai facturat mai mult decât ai livrat luna asta. Cei 800 € intră în soldul curent.
• Profit net = 5.000 − 1.900 − 900 = 2.200 € (calculat față de buget, nu față de cele 4.200 livrate).
Dacă serviciile ar fi însumat 5.600 €, ai fi fost over-serviced (−600 €): aceeași factură de 5.000, dar ai livrat peste buget → semnal de renegociere.

Variația de scop

budget − Σ actuals = cât ai facturat vs. cât ai livrat
buget > livrat → under-serviced (ai „credit")
buget < livrat → over-serviced (mănânci din marjă)
nu apare pe factură — se ține intern ca sold curent (lună de lună), e KPI-ul de renegociere

Profitul

se calculează față de buget, nu față de suma serviciilor
net = budget − supplier_cost − labour_cost
venitul-titlu = bugetul fix; costurile rămân cele reale din servicii

De ce așa (nu billing type)

clientul primește o factură simplă și previzibilă (bugetul)
tu păstrezi calculul real al fiecărui serviciu → rapoarte adevărate
în raportul de profitabilitate: invoiced și delivered_value apar în paralel — nu se amestecă

Regula de reținut la prezentare: bugetul e proprietate a clientului, nu a serviciului. Schimbă o singură cifră (factura). Restul sistemului rămâne pe actuals reale, iar buget − actual = variația de scop, urmărită intern.

06

Întrebările care apar garantat

De ce avem servicii cu profit zero? Nu e o greșeală?

Nu. C și E sunt pass-through: agenția intermediază contractual (clientul vrea o singură factură), iar valoarea se face în alte servicii ale aceluiași client. Modelul refuză să inventeze profit unde nu există — asta face rapoartele credibile. 0 ≠ NULL: zero înseamnă „calculat, și e zero"; NULL înseamnă „încă necalculat".

De ce nu pot pune un nume serviciului?

Numele se compune: asset — grup — departament [— supplier]. Fără text liber, două lucruri devin imposibile: dubluri („SEO Tehnic" vs „Seo tehnic MBS") și servicii ambigue. Cheia unică din DB chiar refuză al doilea serviciu identic pe același asset. Vrei două servicii de Webmastering pe același site? Se poate — cu furnizori diferiți, pentru că supplierul e parte din nume.

Clientul poate afla cât ne costă furnizorul?

Nu, prin construcție. Split-ul cost/fee trăiește doar în service_cost_line (coloane separate unit_cost / unit_fee); în factura clientului pleacă exclusiv client_amount, suma combinată. E regulă de domeniu din spec, nu o opțiune de UI.

Am facturat greșit — cum corectez?

Depinde de moment. Înainte de facturare: editezi costul, iar linia/perioada se resetează singură la cost_entry (fee-ul se reconfirmă). După facturare (invoiced): nimic nu se mai editează — corecția e un storno (factură-oglindă negativă) plus o factură nouă. Istoricul nu se rescrie niciodată în tăcere.

Ce se întâmplă dacă pontez ore după ce luna a fost facturată?

Pontajul pe o lună cu invoiced_at setat e respins. Până la facturare, labour-ul curge liber (de-asta profitul lunii se mișcă și după ce factura e „ready") — după, luna e istorie. Regula există ca raportul de profitabilitate să fie stabil: aceeași întrebare, același răspuns, indiferent când o pui.

Unde e „bugetul lunar" al clientului? Nu văd un billing type pentru el.

Pentru că nu e un billing type — e un overlay la nivel de client (cazul G, §1.11b). Clientul cu buget primește o factură fixă = bugetul, indiferent de servicii. Serviciile lui există și calculează normal, ca actuals: diferența buget − actual e variația de scop (over/under-serviced), urmărită intern ca sold curent. Nimic din schema serviciilor nu se schimbă — doar generarea facturii clientului ia altă cifră. Detaliile complete: secțiunea 05 de mai sus.

De ce nu văd „marja" nicăieri în tabele?

Pentru că v6 a scos-o din vocabular: „margin" nu mai e un număr stocat, ci un ratio de afișare (gross ÷ invoice). Cifra-titlu e net_profit. Motivul: marjele procentuale nu se adună corect între servicii cu volume diferite — sumele da.