Aprobari de discount in Zoho CRM: procesul de aprobare pentru oferte peste prag

Aprobarile de discount in Zoho CRM se construiesc cu un proces de aprobare pe modulul Quotes. Procesul opreste orice oferta cu discount peste prag pana cand o aproba managerul stabilit. Conditia de baza este un camp separat care tine procentul de discount, pentru ca oferta pastreaza discountul ca suma, nu ca procent.

O aprobare de discount este decizia inregistrata in CRM prin care un manager accepta sau respinge o oferta. Este vorba de o oferta al carei discount depaseste limita pe care vanzatorul o poate acorda singur. Decizia ramane pe inregistrare, cu numele celui care a aprobat. Astfel se vede ulterior de ce un client a primit un pret mai mic decat lista.

Ghidul de fata urmeaza ordinea in care merita sa lucrati:

• clarificati cum stocheaza Zoho CRM discountul in oferte;
• calculati procentul intr-un camp separat;
• alegeti pragurile pornind de la discountul standard;
• stabiliti cine aproba fiecare nivel;
• verificati punctele in care fluxul se blocheaza de obicei.

Daca nu aveti inca modulele de oferte si comenzi configurate, incepeti cu ghidul despre configurarea ofertelor si comenzilor in Zoho CRM. Aprobarea de discount se adauga peste acel flux, nu il inlocuieste.

Procesul de aprobare in Zoho CRM este un instrument de automatizare a proceselor care automatizeaza aprobarile in organizatie, conform definitiei Zoho. In cazul discounturilor, procesul primeste ofertele care indeplinesc o conditie si le trimite la o persoana care decide. Oferta asteapta decizia inainte sa mearga mai departe.

My Jobs este locul din Zoho CRM in care aprobatorul vede si aproba cererile dintr-un singur punct. Un manager care aproba discounturi nu trebuie sa caute ofertele prin module. Le gaseste in My Jobs, alaturi de celelalte cereri care il asteapta.

Aprobarile ad-hoc sunt o imbunatatire a proceselor de aprobare din Zoho CRM. Aprobatorul poate adauga alti aprobatori cand are nevoie, fara sa modifice fluxul configurat. Zoho a anuntat functia ca disponibila in toate centrele de date.

In oferte exista doua locuri pentru discount, si diferenta conteaza pentru prag:

• discountul pe linie se aplica unui singur produs din subformularul Quotes Items, adica tabelul cu produsele ofertei;
• discountul pe total se aplica valorii totale a ofertei.

Price Books sunt listele de preturi din Zoho CRM, adica preturi diferite pentru acelasi produs, pe tipuri de clienti. Price Books apar mai jos, pentru ca influenteaza felul in care functioneaza discountul pe linie.

Un proces de aprobare pe discounturi are nevoie de un procent, iar ofertele din Zoho CRM nu il ofera direct. Intr-o discutie din comunitatea Zoho, un utilizator intreaba cum afiseaza procentul de discount in loc de suma in modulele Invoices si Quotes. A incercat campuri de imbinare precum "Quotes.Discount Percentage" si "Quotes.Discount Pct", fara rezultat.

Alte doua situatii din comunitatea Zoho arata aceeasi problema din alt unghi:

• un utilizator care foloseste doar Price Books, fara Unit Price in modulul Products, raporteaza ca discountul procentual pe linie in Quotes accepta valoarea cu %, dar nu produce niciun efect;
• acelasi utilizator raporteaza ca discountul aplicat pe totalul ofertei functioneaza corect;
• un alt utilizator a copiat printr-o formula o valoare dintr-o lista "discount in percent" in campul Discount din Invoices, iar discountul a fost adaugat in USD, nu in procent.

Zoho precizeaza ca exista un camp de tip procent pe care il puteti numi "Discount", dar doar in modulele personalizate. Modulul nativ Deals are deja un camp de discount. Pentru Quotes, concluzia practica este clara. Un prag exprimat in procente cere un camp personalizat de procent, calculat din valorile ofertei. Fara acest camp, regula de aprobare ar compara un prag in procente cu o suma in moneda ofertei.

Procentul de discount se poate calcula in Zoho CRM pe doua cai documentate de Zoho: o functie personalizata Deluge sau un client script. Deluge este limbajul de scripting al Zoho. Un client script este cod care ruleaza in formularul deschis in browser, in timp ce utilizatorul completeaza oferta.

Functia personalizata Deluge

Zoho descrie o functie care scrie discountul in cuvinte, de exemplu "Discount of 5%", intr-un camp text. Aceeasi structura serveste pentru un camp de procent. Pasii din exemplul Zoho sunt:

1. Setup > Developer Space > Functions > + Create New Function;
2. tipul functiei Automation, apoi Next;
3. un argument numit customId, de tip Int.

Functia citeste inregistrarea cu zoho.crm.getRecordById si scrie rezultatul intr-un camp personalizat. Campul din exemplu se numeste "Wording", dar il puteti numi oricum. Zoho noteaza ca exemplul functioneaza doar cu API V2.0.

Client scriptul pe subformularul ofertei

Zoho publica si o solutie care aplica automat discountul pe categorii de produs in oferte. Conform paginii, automatizarile incorporate nu pot aplica singure discount pe liniile ofertei. Solutia foloseste:

• un camp Pick List in Products, cu categoriile de produs;
• un script creat in Setup > Developer Hub > Client Script > +New Script;
• tipul Subform Event, campul Quotes Items si evenimentul onCellChange.

Solutia cere editia Enterprise sau mai mare, iar timpul estimat de implementare este de 30 de minute. Campurile personalizate cer permisiunea Modules Customization, iar scripturile cer Manage Extensibility. Zoho recomanda testarea intr-un sandbox inainte de productie si includerea scriptului si pe paginile Edit si Clone.

Pragurile de discount functioneaza cel mai bine cand pornesc de la discountul standard al fiecarei categorii de produs, nu de la o cifra unica pentru toata firma. In exemplul Zoho pentru oferte, discountul standard difera pe categorii. Kitchen Appliances primeste 30%, Food Preparation 35% si Cleaning Appliances 25%, iar scriptul exemplu acopera sapte categorii.

Un prag unic, de exemplu un singur procent pentru toate ofertele, produce doua erori. Pentru categoriile cu discount standard mare, aproape fiecare oferta ajunge la aprobare. Pentru cele cu discount standard mic, discounturi neobisnuite trec fara control. Un prag relativ la standardul categoriei trimite la manager doar exceptiile reale.

Tabelul de mai jos propune o structura pe niveluri. Valorile concrete ale marjelor le stabileste conducerea comerciala:

Nivel	Conditie pe oferta	Cine decide	Ce verifica decidentul
Standard	Discount egal cu standardul categoriei	Nimeni, oferta trece	Nimic, regula aplica discountul
Marja vanzari	Peste standard, in marja managerului	Managerul de vanzari	Volum, client, istoric de plata
Marja conducere	Peste marja managerului	Directorul comercial	Marja ramasa si precedentul creat
Caz special	Oferta care cere si alt punct de vedere	Aprobatorul adauga ad-hoc o persoana	De exemplu termene de plata sau livrare

Pastrati putine niveluri. Fiecare nivel in plus adauga o persoana care poate intarzia oferta.

Exemplul porneste de la categoriile din solutia Zoho pentru oferte, cu Kitchen Appliances la discount standard de 30%. Presupunem ca directorul comercial a stabilit ca managerul de vanzari aproba singur pana la 35% pe aceasta categorie. Peste 35%, decide directorul. Cifrele de marja sunt ale firmei din exemplu, nu o regula Zoho.

Configurarea decurge astfel:

1. In Products, campul Pick List de categorie primeste valoarea Kitchen Appliances pentru produsele din gama.
2. Client scriptul pe Quotes Items, cu onCellChange, aplica 30% cand vanzatorul alege produsul.
3. Un camp personalizat de procent pe Quotes primeste procentul real de discount, calculat de o functie de tip Automation.
4. Procesul de aprobare pe Quotes are doua conditii: procent peste 30% merge la managerul de vanzari, procent peste 35% merge la director.

Un vanzator negociaza 33% cu un client care cumpara volum mare. Oferta depaseste standardul, deci ajunge in My Jobs la managerul de vanzari. Managerul o aproba, iar oferta poate fi trimisa clientului.

Un alt vanzator cere 40% pentru a castiga un client nou. Oferta trece de ambele praguri si ajunge la director. Directorul vrea si parerea financiarului si il adauga ca aprobator ad-hoc, fara sa modifice fluxul configurat. Numele fiecarui aprobator ramane pe oferta, pentru verificari ulterioare.

Aprobatorul unei oferte cu discount trebuie sa fie persoana care raspunde de marja, nu doar persoana cu cel mai inalt rang. Pentru discounturile mici peste standard, managerul de vanzari cunoaste clientul si negocierea. Pentru discounturile mari, directorul comercial vede efectul asupra marjei totale si asupra precedentului creat pentru alti clienti.

Aprobatorul primeste cererile in My Jobs, locul din Zoho CRM in care aproba cererile dintr-un singur punct. Spuneti explicit fiecarui aprobator ca acolo se uita. Un manager care asteapta un email si nu deschide My Jobs devine, fara sa stie, cauza intarzierilor.

Aprobarile ad-hoc rezolva cazurile pe care nu le-ati prevazut in configurare. Conform anuntului Zoho, aprobatorul adauga alti aprobatori cand are nevoie, fara sa schimbe fluxul configurat. Functia este disponibila pentru toate centrele de date. Folositi aprobarile ad-hoc pentru exceptii rare, de exemplu cand o oferta implica si termene de plata neobisnuite.

Nu folositi aprobarile ad-hoc ca inlocuitor pentru un nivel lipsa. Daca acelasi aprobator este adaugat ad-hoc saptamanal, acel nivel trebuie trecut in procesul de aprobare. Asa ramane vizibil in configurare, nu doar in obiceiurile echipei.

Fluxul de aprobare a discounturilor se blocheaza aproape intotdeauna in date, nu in procesul de aprobare propriu-zis. Punctele de mai jos apar fie in discutiile din comunitatea Zoho, fie in limitarile documentate de Zoho:

• Procentul pe linie nu se aplica cand preturile vin doar din Price Books, conform raportului din comunitatea Zoho, iar campul de procent ramane gol sau gresit.
• Discountul se scrie ca suma cand o formula copiaza un procent in campul Discount, asa cum a patit utilizatorul cu facturile in USD.
• Scriptul lipseste pe Edit si Clone, iar o oferta editata sau clonata pierde discountul standard, asa cum avertizeaza Zoho.
• Cererea asteapta fara termen, pentru ca aprobatorul este in concediu sau nu verifica My Jobs.

Ultimul punct merita o regula scrisa. In comunitatea Zoho, un utilizator intreaba daca o cerere din Zoho Creator, neaprobata dupa mai multe zile, poate fi aprobata sau respinsa automat de sistem. Pentru ofertele din CRM, stabiliti dinainte cine preia cererile unui aprobator absent.

La Svennis verificam, inainte sa activam aprobarea, ca procentul de discount este calculat intr-un camp separat si corect pe oferte create, editate si clonate. Cand acest pas lipseste, vedem la clienti oferte peste prag care trec neobservate, pentru ca regula compara procente cu sume.

Pentru o companie din Romania, pragurile de discount exprimate in procente sunt mai sigure decat pragurile in suma fixa, mai ales cand ofertati si in euro. O limita in lei aplicata unei oferte in euro isi schimba efectul odata cu cursul. Un procent ramane acelasi indiferent de moneda ofertei.

Moneda conteaza si dupa aprobare. Daca pretul ramane exprimat in euro, baza de impozitare se converteste in lei la cursul valabil la data exigibilitatii TVA, conform art. 290 din Codul fiscal. Discountul aprobat pe oferta trebuie sa ajunga deci neschimbat pana in factura. Abia acolo se face conversia in lei.

Fluxul oferta-comanda din Zoho CRM foloseste cinci module legate intre ele. Conversiile suportate sunt din Quotes in Sales Orders sau Invoices si din Sales Orders in Invoices. Aprobarea de discount trebuie plasata inainte de conversie. O oferta convertita inainte de aprobare duce discountul neaprobat mai departe, in comanda si in factura.

Daca facturile pleaca din CRM spre un program de facturare, discountul aprobat ajunge si acolo. Pentru firmele care emit facturi prin SmartBill, integrarea SmartBill cu Zoho CRM preia datele din factura. Verificati de aceea ca procentul aprobat si suma din factura coincid pe cateva oferte de test.

Aprobarile de discount in Zoho CRM se pun in functiune in ordinea de mai jos. Fiecare pas depinde de cel anterior:

1. Notati discountul standard pentru fiecare categorie de produs si marja pe care o poate aproba fiecare manager.
2. Verificati daca folositi doar Price Books, fara Unit Price, si testati discountul pe linie inainte de orice regula.
3. Verificati editia: solutia Zoho cu client script cere Enterprise sau mai mare. Comparatia Zoho One vs Zoho CRM va ajuta daca aveti de ales intre pachete.
4. Creati campul de procent pe Quotes si calculati-l cu o functie de tip Automation sau cu un client script, testat in sandbox.
5. Configurati procesul de aprobare pe Quotes, cu cate o conditie pentru fiecare nivel din tabelul de praguri.
6. Instruiti aprobatorii sa lucreze din My Jobs si stabiliti cine preia cererile in absenta lor.
7. Testati cu oferte create, editate si clonate, apoi convertiti cateva in Sales Orders si Invoices.

Daca doriti sa vedeti cum se leaga aprobarile de restul fluxului de vanzari, pagina despre implementarea Zoho CRM pentru companii din Romania descrie modulele si automatizarile pe care le configuram.

• Zoho CRM: Auto-apply product discounts in subform
• Zoho CRM: Display discount in words
• Comunitatea Zoho: Quotes - Products - Discount percentage does not work
• Comunitatea Zoho: Show discount percentage instead of discount amount
• Comunitatea Zoho: How to add discount in percent?
• Comunitatea Zoho: Automatic Approval
• Svennis: Oferte si comenzi in Zoho CRM, configurare pas cu pas