Integrar WooCommerce amb un ERP en B2B no consisteix a connectar dues APIs i donar el projecte per resolt. La dificultat real és decidir quin sistema mana sobre cada dada, quina informació necessita temps real, com es modelen regles de compte i què passa quan una sincronització falla a mig camí d’una operació.
L’arquitectura correcta no intenta que tots dos sistemes ho sàpiguen tot. Intenta que cadascun sigui responsable d’allò que entén millor i que la integració transporti canvis de manera observable i recuperable.
Quan WooCommerce encaixa en un escenari B2B
WooCommerce pot funcionar molt bé quan el negoci necessita flexibilitat de contingut, catàleg, experiència i extensibilitat, i l’ERP ja concentra clients, preus, comandes o facturació. L’encaix empitjora quan s’espera que WordPress repliqui una lògica comercial extremadament complexa que ja existeix en un altre sistema i canvia constantment.
La pregunta no és si WooCommerce “pot” fer una regla concreta; gairebé sempre es pot desenvolupar. La pregunta és on ha de viure aquesta regla perquè continuï sent governable d’aquí tres anys.
Primer: crear una matriu de fonts de veritat
Abans d’escriure integració, llista els dominis principals: client, usuari, adreça, catàleg, atributs, preu, disponibilitat, comanda, factura, crèdit, enviament i document. Per a cadascun defineix sistema propietari i consumidors.
En una integració WooCommerce ERP típica, ERP sol manar sobre compte, condicions comercials, preu final, crèdit, comanda i factura. WooCommerce pot manar sobre sessió, contingut editorial, navegació, carret previ a confirmació i certes preferències d’usuari. PIM pot ser propietari de l’enriquiment de producte.
Clients i comptes: no confondre usuari amb client
WordPress pensa de manera natural en usuaris; B2B pensa en comptes amb diversos usuaris. La integració necessita una capa que relacioni usuaris individuals amb una entitat de client ERP. Aquesta relació ha de suportar rols, centres, permisos i canvis de personal.
No utilitzis l’email com a únic identificador permanent si el negoci té comptes corporatius complexos. Conserva IDs d’ERP i claus estables. Un usuari pot canviar d’email; una empresa es pot fusionar; dos contactes poden compartir domini sense pertànyer al mateix compte.
Preus: calcular o sincronitzar
Hi ha dos grans patrons. El primer sincronitza llistes i regles a WooCommerce i calcula localment. El segon consulta l’ERP o un pricing service durant l’experiència. El model local és més ràpid i tolerant a caigudes; el remot redueix duplicació de lògica.
La decisió depèn de freqüència de canvis, complexitat i necessitat d’exactitud immediata. Un preu contractual que canvia un cop al trimestre es pot sincronitzar. Una cotització dependent de matèries primeres o regles complexes pot requerir càlcul remot.
En tots dos casos ha d’existir una manera d’explicar discrepàncies: quin preu es va mostrar, amb quina versió de dades i quin valor va rebre finalment l’ERP.
Estoc i disponibilitat: la xifra no sempre és la promesa
L’estoc físic de l’ERP pot no equivaler a quantitat vendible. Hi ha reserves, magatzems, lots, comandes en curs i regles d’assignació. Dissenya un concepte de disponibilitat adequat al comprador: unitats disponibles, data estimada, disponibilitat per magatzem o simplement estat.
Per a referències crítiques es pot utilitzar consulta en temps real. Per a catàlegs grans, una combinació de snapshots freqüents i validació final abans de confirmar comanda sol ser més eficient.
Catàleg: ERP no sempre és PIM
Molts ERP contenen SKU i descripció administrativa, però no la informació necessària per vendre: beneficis, aplicacions, compatibilitats, documents, imatges o taxonomia. No forcis l’ERP a convertir-se en PIM només perquè ja existeix.
Quan hi ha PIM, WooCommerce hauria de rebre contingut enriquit des d’ell i dades transaccionals des de l’ERP. Defineix regles de merge per evitar que una sincronització administrativa esborri contingut comercial.
Comandes: dissenyar una màquina d’estats
El moment més delicat és el traspàs de la comanda. Decideix quan WooCommerce considera l’operació acceptada: en crear la comanda local, en rebre confirmació ERP o després de validar crèdit. Cada elecció té conseqüències d’UX i suport.
Una arquitectura robusta utilitza IDs de correlació i idempotència. Si es reintenta la mateixa petició, no s’ha de crear una segona comanda. Guarda resposta ERP i estat d’integració de manera separada de l’estat comercial mostrat al client.
Webhooks, cues i processos batch
Els webhooks són bons per avisar de canvis ràpids, però no haurien de ser l’única garantia. Es poden perdre, duplicar o arribar fora d’ordre. Les cues permeten desacoblar sistemes i reintentar. Els processos batch serveixen com a reconciliació.
Un patró sòlid combina esdeveniments per velocitat i una rutina periòdica que comprova que tots dos costats continuen coherents. Per exemple, el webhook actualitza l’estat de comanda i una reconciliació nocturna detecta comandes que no van rebre esdeveniment.
Reintents sense duplicar efectes
Tot procés remot hauria d’assumir que hi haurà timeouts. Si no sabem si ERP va rebre una petició abans que la connexió es tallés, repetir-la sense clau idempotent pot duplicar comandes. Dissenya operacions que es puguin reintentar amb seguretat.
Diferencia errors temporals —timeout, servei caigut— d’errors de negoci —client bloquejat, referència no vàlida—. Els primers es poden reintentar automàticament; els segons necessiten intervenció o missatge a l’usuari.
Una cua d’excepcions és part del producte
Les integracions B2B no han d’ocultar fallades en un log tècnic. Crea una vista operativa d’excepcions: comanda pendent d’ERP, preu sense resposta, client no mapat, document fallit. Assigna responsable i acció possible.
L’objectiu no és aconseguir zero errors, sinó detectar i resoldre ràpidament els inevitables sense que el client sigui qui descobreixi el problema.
Observabilitat: què s’hauria de mesurar
- Latència per tipus d’operació.
- Taxa de fallades i reintents.
- Missatges a dead-letter queue.
- Diferències detectades en reconciliació.
- Comandes duplicades evitades per idempotència.
- Antiguitat de l’última dada de preu i estoc.
- Errors per versió d’API o sistema.
Aquestes dades haurien de generar alertes quan superen llindars. Revisar logs manualment només després que un client truqui no és observabilitat.
Seguretat i dades
No exposis credencials ERP al navegador. La integració s’ha d’executar en servidor o middleware, amb secrets gestionats i privilegis mínims. Registra accions sensibles sense guardar més dades personals de les necessàries.
Si el portal permet informació comercial confidencial, valida que cada consulta estigui filtrada per compte. Un error de caché o autorització que barreja preus entre clients és un incident greu.
Com provar una integració WooCommerce ERP
Utilitza comptes representatius i escenaris extrems: canvi de tarifa durant una sessió, estoc esgotat entre carret i confirmació, ERP lent, comanda parcial, usuari sense permís, devolució, moneda diferent i referència discontinuada. Prova també recuperació després de caiguda.
Les proves de contracte entre APIs ajuden a detectar canvis abans de producció. Si ERP actualitza versió, l’equip ecommerce hauria de saber si algun camp crític canvia.
SEO i GEO continuen sent part del sistema
La integració sosté la transacció, però la part pública necessita contingut indexable i comprensible. Dades de producte riques, pàgines d’aplicació, documentació i relacions clares entre famílies permeten posicionar i ser citats per motors generatius.
Evita que una dependència de l’ERP faci que cercadors rebin pàgines buides quan el sistema va lent. El contingut públic important s’ha de poder servir de manera resilient.
Preguntes freqüents
Cal temps real per a tot?
No. Utilitza temps real on la decisió depèn d’informació immediata. Per a la resta, sincronització freqüent i reconciliació pot ser més simple i fiable.
És millor integrar directament o utilitzar middleware?
La connexió directa pot ser suficient en escenaris simples. Middleware aporta valor quan hi ha diversos sistemes, transformacions, cues, observabilitat o necessitat de desacoblar canvis.
Qui ha de monitoritzar la integració?
Necessita una responsabilitat operativa clara. Desenvolupament pot mantenir la tecnologia, però negoci i operacions han de tenir visibilitat sobre excepcions que afecten comandes i clients.
Dissenyar una capa anticorrupció entre ERP i ecommerce
Quan l’ERP utilitza estructures antigues o nomenclatures pensades per back office, no convé copiar-les directament al domini ecommerce. Una capa de transformació pot convertir codis, estats i models de dades a conceptes estables orientats al canal digital. Això evita que cada canvi d’ERP obligui a modificar lògica de frontend.
La capa també facilita proves i observabilitat: pot validar contractes, rebutjar missatges incomplets i registrar transformacions. En arquitectures amb diversos canals, la mateixa integració pot alimentar ecommerce, portal de distribuïdors i aplicacions sense duplicar adaptadors.
Versionat i canvis controlats
Defineix versions d’API i contractes de payload. Un nou camp opcional és diferent de reanomenar un identificador utilitzat en producció. Els equips han de conèixer amb antelació canvis incompatibles i disposar d’entorn de proves. Les integracions crítiques mereixen calendari de manteniment i rollback igual que qualsevol altre component de producte.
Reconciliació financera i de comandes
No n’hi ha prou amb comprovar que l’API va respondre 200. Compara periòdicament comandes, totals, impostos, estats i devolucions entre sistemes. Una reconciliació diària detecta diferències silencioses que els logs tècnics no consideren error. Aquesta capa és especialment important quan hi ha pagaments, crèdit o facturació automatitzada.
Responsabilitat: qui decideix quan les dades no coincideixen
Les discrepàncies no són només un problema tècnic. Si WooCommerce i ERP mostren diferent preu o estat, ha d’existir un propietari de negoci que defineixi la regla correcta i un propietari tècnic que implementi la correcció. Sense aquesta separació, els equips poden passar hores buscant “quin sistema està malament” sense una política sobre quin hauria de manar.
Crea un runbook amb responsables, escalat i exemples d’incidents. Això redueix temps de diagnòstic i permet incorporar nous membres sense dependre de coneixement oral.