Resposta directa: els preus B2B per client no s’han de modelar com còpies del catàleg ni com una cadena de descomptes acumulats. El model més fiable separa quatre elements: qui compra (compte, empresa o delegació), què pot comprar (catàleg i assortiment), quin preu contractual li correspon (moneda, unitat, vigència i trams) i quina regla preval quan coincideixen diverses condicions. Aquesta precedència s’ha de calcular igual a la fitxa de producte, el carret, el checkout, la comanda i l’ERP.
Si una tarifa és correcta a la pantalla però canvia quan s’envia la comanda, el sistema no té un model de preus: té interpretacions incompatibles. L’objectiu operatiu és que una mateixa entrada —compte, SKU, quantitat, data, mercat, moneda i unitat de venda— produeixi sempre el mateix preu i que se’n pugui explicar el motiu.
L’error inicial: confondre catàleg, tarifa i descompte
En B2B, el catàleg respon «aquest client pot veure i comprar aquest producte?». La tarifa respon «quin és el preu base autoritzat per a aquest compte?». El descompte respon «quin ajust addicional es pot aplicar a aquesta operació?». Barrejar-los crea excepcions difícils d’auditar: productes duplicats, promocions que trepitgen contractes, imports públics visibles per a comptes privats o preus diferents entre l’ecommerce i l’ERP.
Una arquitectura mantenible conserva un únic identificador de producte i relaciona l’SKU amb regles d’accés i preu. Només convé duplicar un producte quan en canvia realment la identitat comercial o logística, no per representar cada contracte.
La clau mínima del càlcul
Abans d’escollir plataforma, defineix la clau que identifica una decisió de preu. Com a mínim hauria d’incloure:
- account_id o company_location_id: l’entitat contractual que compra, no només l’usuari connectat.
- sku o variant_id: la unitat comercial exacta.
- quantity: quantitat expressada en la unitat sobre la qual es va negociar el preu.
- unit_of_measure: unitat, caixa, palet, metre o quilogram, amb el factor de conversió.
- currency i market: moneda i àmbit fiscal o geogràfic.
- effective_at: data i hora de validesa del contracte.
- channel: ecommerce, comercial, EDI o portal, si les condicions autoritzades són diferents.
L’usuari és una credencial; el compte o la delegació és la contrapart comercial. Si una persona compra per a diverses empreses, el sistema l’ha d’obligar a seleccionar el compte actiu i recalcular catàleg, crèdit, impostos i preus. Heretar l’últim compte sense mostrar-lo és una causa habitual de comandes mal valorades.
Una jerarquia de preus que es pugui explicar
No hi ha una jerarquia universal, però sí una condició obligatòria: ha d’estar escrita, versionada i provada. Un exemple raonable és:
- Preu contractual per compte + SKU, vigent i en la moneda i unitat sol·licitades.
- Preu contractual per grup de comptes + SKU, si no hi ha una excepció individual.
- Tarifa del catàleg assignat a l’empresa o delegació.
- Preu B2B general del mercat, només si el contracte permet aquesta alternativa.
- Sense preu de venda: sol·licitud de pressupost o bloqueig explícit.
Dins del nivell guanyador s’apliquen, en un ordre definit, els trams per quantitat i els descomptes permesos. No s’ha de pressuposar que «el preu més baix» sempre és la regla correcta: podria vulnerar un contracte, consumir marge o combinar dos incentius incompatibles. Algunes plataformes trien l’import inferior entre catàlegs elegibles; d’altres apliquen una lògica de selecció per àmbit. Per això la regla de negoci ha de ser pròpia i no una conseqüència accidental del motor.
Exemple de resolució
| Dada | Valor | Decisió |
|---|---|---|
| Compte | ACME Barcelona | Contracte C-2026-041 |
| SKU / unitat | VAL-80 / caixa de 10 | No convertir des d’un preu unitari sense una regla autoritzada |
| Data | 15/10/2026 | Versió contractual vigent des de l’01/10/2026 |
| Quantitat | 20 caixes | Tram 20–49 |
| Preu resolt | 184,00 EUR/caixa | Contracte individual; promoció general exclosa |
La resposta del servei de preus no hauria de retornar només 184.00, sinó també moneda, unitat, preu net o brut, identificador i versió de la regla, dates de vigència i motiu de selecció. Sense aquesta explicació, l’equip de suport no pot reconstruir una incidència.
Contractes, volum i promocions: decidir l’acumulació
Cada regla necessita un atribut de compatibilitat. Per a cada contracte, defineix si el preu és:
- net i final: exclou promocions i cupons;
- base negociada: admet determinats descomptes posteriors;
- per volum: substitueix el preu quan s’assoleix un tram;
- retroactiu: es liquida fora de la comanda mitjançant ràpel o abonament;
- cotitzable: necessita aprovació abans de convertir-se en comanda.
Els mínims, màxims i increments de compra s’han d’avaluar sobre la mateixa variant i unitat que els trams. Si el producte es ven en caixes de 10, un tram de 100 unitats equival a 10 caixes només quan la conversió està governada i no canvia segons el mercat o la presentació. Shopify documenta, per exemple, que les seves regles de quantitat i preus per volum s’apliquen a variants i que els trams han de respectar mínims i increments. És un bon principi de disseny per a qualsevol implementació, encara que es faci servir una altra plataforma.
Quin sistema ha de ser propietari de cada dada
| Dada | Font mestra habitual | Responsabilitat de l’ecommerce |
|---|---|---|
| SKU, unitat i conversió | ERP o PIM | Validar que la variant comprada coincideix |
| Compte, grup i delegació | ERP o CRM | Resoldre la identitat activa de compra |
| Contracte i vigència | ERP/CPQ | Consumir una versió publicada i traçable |
| Assortiment visible | PIM/commerce | Aplicar el catàleg per compte o ubicació |
| Preu mostrat | Servei de preus | No recalcular-lo amb una lògica divergent |
| Preu acceptat a la comanda | Commerce + validació ERP | Desar la regla, la versió i el desglossament |
Evita que l’ERP i l’ecommerce editin la mateixa regla. El patró més estable és publicar una versió immutable de la tarifa, activar-la en una data i conservar l’anterior per a auditoria. Si arriba una correcció, se’n publica una versió nova; no se sobreescriu silenciosament la que va valorar comandes existents.
Sincronització i validació amb l’ERP
La importació de preus no acaba quan el fitxer o l’API respon «correcte». Cal reconciliar:
- comptar regles rebudes, acceptades, rebutjades i caducades;
- validar moneda, unitat, SKU, compte, dates superposades i trams;
- comparar una mostra determinista de preus entre origen i destinació;
- publicar la versió només si supera els llindars;
- emetre una alerta amb els identificadors rebutjats;
- revalorar la comanda a l’ERP i bloquejar-ne la confirmació si la diferència supera la tolerància autoritzada.
L’ecommerce ha d’enviar a l’ERP el preu, l’identificador de la regla i la seva versió. Si l’ERP retorna un import diferent, no convé substituir-lo en silenci: el comprador ha de saber si la comanda queda retinguda, requereix aprovació o s’ha de recalcular.
Memòria cau i privacitat: un preu privat no pot travessar comptes
La memòria cau d’una fitxa o API ha de variar, com a mínim, per compte o catàleg efectiu, mercat, moneda, unitat i estat d’autenticació. Una URL comuna amb HTML desat només per ruta pot mostrar a un client el preu d’un altre. Separa el contingut públic emmagatzemable del preu privat; a les API, utilitza claus explícites i evita desar respostes personalitzades en xarxes compartides.
Els preus contractuals no haurien d’aparèixer en dades estructurades públiques, feeds oberts, cercadors interns anònims ni fragments generats al servidor abans de resoldre el compte. En tancar sessió o canviar d’empresa, invalida el carret, el preu i els permisos associats a la identitat anterior.
Què cal fer quan falta un preu
Un zero, el preu públic o l’últim valor de la memòria cau no són alternatives segures. Defineix per contracte un d’aquests resultats: bloquejar la compra amb una explicació, permetre una sol·licitud de pressupost, recuperar el preu en temps real o usar una tarifa general expressament autoritzada. Registra’n el motiu i genera una alerta si creix la taxa de productes sense preu.
Durant una caiguda de l’ERP, la continuïtat es pot basar en l’última versió publicada i encara vigent, mai en una versió caducada sense avisar. L’empresa ha de fixar quant temps és acceptable operar així i quines comandes requeriran una revisió posterior.
Proves abans de publicar
Una bateria mínima ha d’incloure:
- dos usuaris del mateix compte obtenen el mateix resultat;
- un usuari amb dues empreses canvia de context sense arrossegar preus ni carret;
- dos comptes amb el mateix SKU veuen les tarifes correctes;
- el segon exacte d’inici i final de vigència resol la versió esperada;
- mínim, increment i cada frontera de volum: per sota, exacta i per sobre;
- canvi de moneda, mercat i unitat sense conversions implícites;
- contracte incompatible amb una promoció o un cupó;
- producte sense tarifa, tarifa caducada i compte sense catàleg;
- fitxa, carret, checkout, comanda, correu i ERP mostren el mateix desglossament;
- memòria cau freda i calenta, tancament de sessió i canvi de compte no filtren preus.
Mètriques que detecten una degradació real
Controla el percentatge de línies sense preu, diferències ecommerce–ERP, comandes retingudes per valoració, latència del servei de preus, regles rebutjades durant la importació i reclamacions per discrepància. Segmenta per compte, mercat, catàleg i versió; una mitjana global pot amagar que un contracte concret ha quedat fora de sincronització.
Preguntes freqüents
Convé crear una tarifa per client?
Només quan hi ha una condició realment individual. Si centenars de comptes comparteixen condicions, utilitza un grup o catàleg comú i afegeix excepcions per compte. Així redueixes regles duplicades sense perdre precisió contractual.
S’ha de mostrar el preu abans d’iniciar sessió?
Depèn de la política comercial. El preu públic es pot mostrar als visitants, però no s’ha de confondre mai amb el contractual. Si tot el preu és privat, mostra l’accés o la sol·licitud de compte i evita exposar-lo en HTML, feeds o dades estructurades públiques.
Què passa si coincideixen dos contractes?
La càrrega ha de rebutjar la superposició o resoldre-la amb una prioritat explícita. Triar el preu inferior o l’última fila importada sense una regla aprovada fa que el resultat sigui imprevisible.
On es calculen els impostos?
El model de preus ha de declarar si els imports són nets o bruts i qui determina el règim fiscal. L’impost pot dependre de l’adreça, el tipus de client i el producte; no s’ha d’incrustar de manera ambigua dins d’una tarifa contractual.
Fonts primàries per contrastar el model
- Shopify: catàlegs i preus B2B, per a l’assignació de catàlegs, empreses i ubicacions.
- Shopify: regles de quantitat i preus per volum, per a mínims, increments i trams per variant.
- commercetools: selecció de preus i descomptes, per a àmbits, grups de clients i precedència.
- Adobe Commerce: catàlegs compartits, per a abast, preus personalitzats i assignació a empreses.
Pas següent
Abans de migrar tarifes o afegir descomptes, construeix una taula de decisió amb deu comandes reals i obliga negoci, ecommerce i ERP a explicar el mateix resultat. Si necessites revisar l’arquitectura, la jerarquia i les proves del teu cas, consulta els recursos de CODE B2B.