Resposta directa: una jerarquia de compte B2B ha de representar qui compra, per a quina unitat organitzativa ho fa, quin pressupost pot utilitzar i qui ha d’aprovar l’operació. No n’hi ha prou amb crear perfils de «comprador» i «administrador». El portal ha de separar l’entitat legal, les divisions o seus, els centres de cost, les adreces, els rols i les regles d’aprovació; també ha de conservar quins permisos són directes i quins s’han heretat.
La prova que el model funciona no és que l’usuari pugui iniciar sessió. És que dues persones de la mateixa empresa, amb responsabilitats diferents, vegin exactament els catàlegs, les adreces, els pressupostos i les comandes que els corresponen, i que una absència, una revocació o un canvi organitzatiu no deixi comandes bloquejades ni accessos residuals.
Modela primer l’organització i després els usuaris
Una persona pot canviar de lloc de treball, operar per a diverses seus o aprovar temporalment per a una altra unitat. Per això els permisos no haurien de penjar directament del seu correu electrònic. El model base hauria de distingir:
- Entitat legal: l’organització que contracta, rep les factures i assumeix el crèdit.
- Unitat de compra: divisió, filial, delegació, planta o projecte que fa comandes.
- Centre de cost: dimensió comptable a la qual s’imputa la despesa.
- Ubicació: adreces de lliurament i facturació autoritzades.
- Usuari: identitat autenticada que actua per a una o diverses unitats.
- Rol: conjunt de permisos dins d’una unitat concreta.
No copiïs sense més l’organigrama de recursos humans. La jerarquia del portal ha de reflectir el procés de compra. Una empresa pot tenir vint departaments, però només tres àmbits rellevants per a les comandes: Espanya, Portugal i grans projectes. El nivell correcte és el mínim que permet aplicar accés, pressupost, catàleg, adreça i aprovació sense excepcions manuals.
Què s’hereta i què ha de ser explícit
Per a cada dada, decideix si una unitat filla l’hereta del pare, l’amplia o la substitueix. Documenta la decisió en una matriu:
| Element | Herència recomanada | Excepció habitual |
|---|---|---|
| Rols corporatius | Heretables si el rol ho indica | Una planta restringeix l’aprovació a personal local |
| Regles d’aprovació | Regla corporativa + regles locals | Projecte amb límits més estrictes |
| Catàleg | Des de la unitat comercial superior | Filial amb assortiment regulat |
| Adreces | Explícites | No exposar totes les seus a tots els compradors |
| Centre de cost | Explícit o limitat per àmbit | Un usuari pot imputar només a dos projectes |
| Condicions de pagament | Entitat legal | Delegació amb acord propi |
L’herència redueix el manteniment, però també amplia l’abast d’un error. Si l’administrador corporatiu rep un rol heretable, pot actuar a totes les unitats filles. El portal ha de mostrar l’origen del permís —directe o heretat d’una unitat identificada— perquè suport pugui explicar per què una persona té accés.
Dissenya els rols per capacitat, no pel nom del càrrec
Evita rols vagues com «usuari avançat». Construeix permisos atòmics i agrupa’ls en arquetips comprensibles:
| Rol | Pot | No hauria de poder per defecte |
|---|---|---|
| Sol·licitant | Crear llistes i sol·licituds | Aprovar la seva pròpia sol·licitud |
| Comprador | Crear i enviar comandes dins de política | Modificar usuaris o regles |
| Aprovador | Veure el context i aprovar o rebutjar | Canviar la comanda sense retornar-la |
| Finances | Consultar factures, crèdit i centres de cost | Administrar compradors |
| Administrador de compte | Convidar, suspendre i assignar rols permesos | Elevar els seus privilegis |
| Auditor | Consultar comandes, decisions i registres | Executar operacions |
Aplica el privilegi mínim i la segregació de funcions. Un sol·licitant no ha d’aprovar la seva compra; un administrador del client no hauria d’atorgar permisos superiors als seus; i el suport del venedor no hauria de suplantar un comprador sense autorització, motiu i registre temporal.
Centres de cost, pressupostos i límits
El centre de cost no és un camp de text lliure al final del checkout. Ha de ser una referència vàlida, vigent i autoritzada per a la unitat i l’usuari. Cal decidir:
- si és obligatori per a totes les línies o per a la comanda completa;
- si una comanda es pot repartir entre diversos centres;
- qui pot canviar-lo després de l’aprovació;
- si el pressupost es reserva en enviar, aprovar o confirmar;
- què passa quan l’ERP rebutja la combinació comptable.
Distingeix límit de comanda, pressupost disponible i autoritat d’aprovació. Un comprador pot tenir permís per crear una sol·licitud de 20.000 euros encara que només pugui confirmar directament fins a 2.000; la resta entra en aprovació. El pressupost determina si la unitat pot assumir la despesa, no qui prem «aprovar».
Regles d’aprovació deterministes
Una regla ha d’indicar àmbit, condició, aprovador o grup d’aprovadors, ordre i resultat si ningú respon. Les condicions habituals combinen:
- import net o brut i moneda normalitzada;
- unitat, centre de cost o projecte;
- categoria, producte restringit o proveïdor;
- desviació respecte del pressupost o contracte;
- adreça de lliurament o país;
- tipus de comprador i canal.
Exemple: «Per a la planta BCN-02, una comanda de material de laboratori superior a 5.000 EUR necessita primer el responsable del centre de cost i després Compliment normatiu. El sol·licitant mai no pot ser aprovador». Si coincideixen diverses regles, defineix si es fusionen, si preval la més restrictiva o si segueixen rutes paral·leles. No depenguis mai de l’ordre accidental en què es van desar.
Estats mínims del flux
La comanda hauria de distingir esborrany, enviada, pendent d’aprovació, aprovada, rebutjada, retornada per a canvis, caducada, cancel·lada i enviada a l’ERP. Cada transició necessita actor, data, comentari opcional o obligatori i versió de la comanda. Si el comprador modifica quantitat, adreça, centre de cost o preu després de l’aprovació, aquesta s’invalida i la ruta es recalcula.
Delegacions, vacances i escalat
Una delegació ha de tenir titular, substitut, abast, inici, final i motiu. No copiïs indefinidament tots els permisos de l’aprovador. Limita la substitució a unitats i capacitats concretes, impedeix la delegació circular i avisa tant el titular com el substitut.
Defineix també un acord de nivell de servei: recordatori a les 24 hores, escalat a les 48 i caducitat o reassignació a les 72, per exemple. El sistema no ha d’autoaprovar per silenci. Si no hi ha un aprovador vàlid, mostra el bloqueig al comprador i notifica l’administrador del compte amb una acció concreta.
Altes, canvis i baixes sense permisos residuals
El cicle de vida és més important que l’alta inicial:
- Una invitació caduca, està vinculada a una empresa i no concedeix permisos fins que es verifica.
- L’administrador assigna només rols dins del seu àmbit.
- Els canvis d’unitat recalculen permisos heretats i comandes pendents.
- La suspensió revoca sessions i tokens actius, no només amaga l’usuari.
- La baixa reassigna tasques pendents i conserva l’historial amb una identitat immutable.
Sincronitza les referències mestres amb l’ERP, el CRM o el proveïdor d’identitat, però defineix quin sistema governa cada atribut. Si el CRM diu que una persona està activa i el directori corporatiu l’ha desactivada, la política de seguretat ha de resoldre el conflicte explícitament.
Una auditoria que reconstrueixi la decisió
Registra qui va actuar, per a quina unitat, amb quin rol efectiu, sobre quina versió, des de quin canal i què va canviar. Per a una aprovació, conserva regla i versió, condicions avaluades, candidats, decisió, comentari, delegació utilitzada i resultat enviat a l’ERP. Evita dades sensibles innecessàries, protegeix el registre contra alteracions i fixa la retenció segons la política legal.
Proves imprescindibles abans de publicar
- Un usuari d’una filial no veu adreces, comandes ni centres d’una altra.
- Un rol heretat apareix només a les unitats permeses i en mostra l’origen.
- El sol·licitant no aprova la seva comanda, ni tan sols mitjançant delegació.
- Es proven imports just per sota del límit, exactament al límit i just per sobre.
- Dues regles simultànies generen sempre la mateixa ruta.
- Un canvi material invalida l’aprovació anterior.
- Absència, substitució, escalat, rebuig i caducitat acaben sense bloqueig ocult.
- La suspensió talla les sessions i reassigna els pendents.
- L’ERP rep entitat legal, unitat, centre de cost i traçabilitat correctes.
- Un auditor pot reconstruir el flux sense accés d’escriptura.
Preguntes freqüents
Quants nivells ha de tenir la jerarquia?
Els mínims necessaris per expressar l’accés i la política de compra. Afegir nivells de l’organigrama sense efecte operatiu augmenta les excepcions i dificulta entendre l’herència.
Un usuari pot pertànyer a diverses unitats?
Sí, però el context actiu ha de ser visible i cada comanda ha de quedar lligada a una sola unitat compradora. En canviar de context es recalculen catàleg, adreces, centres i permisos.
Qui administra els usuaris del client?
Un administrador de compte pot gestionar l’àmbit delegat, però la plataforma ha d’impedir que s’atorgui privilegis superiors o que modifiqui controls reservats al venedor.
Què passa si l’aprovador causa baixa?
La comanda s’ha de reavaluar amb la versió vigent de la política i s’ha de reassignar o escalar. L’historial ha de conservar qui era el candidat original i per què va canviar la ruta.
Fonts primàries per contrastar el disseny
- commercetools: Business Units, per a companyies, divisions, associats i herència de regles.
- commercetools: rols i permisos d’associats, per a capacitats granulars i segregació entre sol·licitud i aprovació.
- Microsoft Dynamics 365 Commerce: jerarquies de clients B2B, per a organitzacions, persones i control d’accés.
- Microsoft Dynamics 365 Commerce: jerarquies organitzatives, per a unitats, centres de cost, vigència i historial.
Pas següent
Construeix tres casos reals —compra dins del límit, compra amb doble aprovació i absència de l’aprovador— i exigeix que el portal i l’ERP produeixin la mateixa unitat, centre de cost i decisió. Per aprofundir en el disseny funcional del portal, consulta els recursos de CODE B2B.