Cada comanda en una sola línia de temps, de l’entrada a la factura cobrada.
De la comanda al cobrament, de la compra al pagament i de la petició de servei a la factura, els processos passen per l’ERP, el CRM, el comerç electrònic, el magatzem, el transport i les finances. Els connectem amb API i esdeveniments documentats, donem a cada comanda un sol estat en tots aquests sistemes i enviem cada excepció a un agent que prepara una solució perquè una persona l’aprovi.
Per a empreses que venen, compren i facturen a Espanya i en altres estats membres, cadascun amb els seus sistemes, transportistes i normes de facturació.
Planificació logística i de la cadena de subministrament
Equips de comptes a pagar i a cobrar
Integració i operacions TIC
Flux de treball il·lustratiu
01Registre únic de l’esdevenimentSistema
02Distribució per API i esdevenimentsSistema
03Una línia de temps per comandaSistema
04Context i propostaAgent d’IA
05Aprovació dins dels llindarsPersona
06Facturació, aparellament i cobramentSistema
07Revisió del flux i correcció de causesPersona
Una comanda de venda, una comanda de compra o una petició de servei es registra una sola vegada al seu sistema de referència i es distribueix als altres sistemes per mitjà d’API i esdeveniments documentats. Els esdeveniments d’estat construeixen una sola línia de temps per comanda. Quan un pas falla o surt de la tolerància, un agent reuneix el context i proposa una solució, que una persona aprova abans que s’executi al sistema de referència. Les factures s’intercanvien i s’aparellen com a factures electròniques estructurades, i les persones responsables dels processos revisen el flux i l’estat de les interfícies.
Abans i després
Què canvia en les operacions diàries
Avui
Amb el sistema
Avui
Avui: Es torna a teclejar a cada traspàs
Una comanda presa a la botiga en línia o per l’equip comercial es torna a teclejar a l’ERP, i les dades de lliurament i de facturació es copien a mà als sistemes de magatzem, transport i finances.
Amb el sistema
Amb el sistema: Una sola entrada, ús a tot arreu
Cada comanda, lliurament i factura es crea al sistema de referència i es publica com a esdeveniment. Els altres sistemes s’hi subscriuen en lloc de tornar-la a teclejar.
Avui
Avui: L’estat d’ahir
Les interfícies per lots nocturnes fan que atenció al client, planificació i finances vegin cadascun un estat diferent i desfasat de la mateixa comanda. Qui pregunta on és un lliurament ha d’esperar que li tornin la trucada.
Amb el sistema
Amb el sistema: Un sol estat actual
Cada comanda o petició té una sola línia de temps construïda amb els esdeveniments de tots els sistemes per on passa. Atenció al client, planificació i finances veuen els mateixos fets, i també la solució Atenció al públic quan respon preguntes sobre l’estat.
Avui
Avui: Excepcions gestionades a les bústies
Les faltes d’estoc, les diferències de preu, els lliuraments fallits i les factures electròniques rebutjades es resolen per correu i amb fulls de càlcul, i després ningú no pot dir qui va decidir què.
Amb el sistema
Amb el sistema: Les excepcions arriben amb una proposta
Un agent recull les dades que hi ha darrere de cada excepció i proposa una solució. Una persona l’aprova, l’edita o la rebutja en un sol tauler d’excepcions, i la decisió queda registrada.
Avui
Avui: Dades mestres que no coincideixen
El mateix client, proveïdor, producte o preu existeix en diversos sistemes amb valors diferents, i ningú no és responsable de decidir quin és el correcte.
Amb el sistema
Amb el sistema: Un responsable per a cada objecte de dades
Clients, proveïdors, productes i preus tenen cadascun un sistema de referència acordat i una persona responsable. Els duplicats i els conflictes s’informen a aquesta persona, no es corregeixen en silenci més avall.
Avui
Avui: Cada canvi afegeix una interfície
Un canal de venda nou, un marketplace o una nova societat del grup vol dir un altre enllaç punt a punt. La factura electrònica obligatòria afegeix, a sobre, un format estructurat i un canal d’intercanvi a cada procés.
Amb el sistema
Amb el sistema: Les connexions noves reutilitzen els mateixos contractes
Un canal nou, una societat nova o una plataforma de factura electrònica es connecta una sola vegada a API i esdeveniments documentats, en lloc de connectar-se a cada sistema per separat.
Flux de treball
Com funciona el flux de treball
Quan les dades són netes, el camí principal no necessita feina manual. Quan una comanda, un lliurament o una factura es desvia, el bucle d’excepcions la porta a una persona amb l’evidència i una proposta, i la correcció aprovada torna a circular per la mateixa capa d’integració.
Flux de treball il·lustratiu
7 passos · 1 punt de control humà
Llegenda
Sistema
Agent d’IA
Persona
Punt de control humà
Via d’excepció
Processos connectats: flux il·lustratiu amb bucle d’excepcions
Llegiu el diagrama en format de text
El camí principal va del registre únic d’un esdeveniment de negoci al seu sistema de referència a la distribució als altres sistemes per API i esdeveniments i a la construcció d’una línia de temps per comanda, i d’aquí a la facturació, l’aparellament i el cobrament. Acaba amb les persones responsables dels processos revisant el flux i corregint les causes de les excepcions.
Quan un pas falla, s’endarrereix o surt de la tolerància, l’excepció surt del camí principal després del pas de la línia de temps. Un agent reuneix el context i proposa una solució, i una persona l’aprova, l’edita o la rebutja. L’acció aprovada s’executa al sistema de referència i torna al pas de distribució com un esdeveniment nou.
El pas d’aprovació és el punt de control humà: no es fa cap registre financer, cap canvi de preu o de límit de crèdit ni cap compromís amb un client sense una persona.
01
Pas 1: Registre únic de l’esdevenimentSistema
Una comanda de venda de la botiga en línia, d’un marketplace, per EDI o de l’equip comercial, una comanda de compra o una petició de servei es crea al sistema de referència. Aquest sistema publica un esdeveniment de negoci en un sobre CloudEvents, descrit en un contracte AsyncAPI. Les comandes en paper o en PDF i les factures de proveïdors passen primer per la solució Processament de documents.
02
Pas 2: Distribució per API i esdevenimentsSistema
La capa d’integració lliura l’esdeveniment als sistemes de magatzem, transport, finances i CRM per mitjà de les seves API documentades (OpenAPI). Els consumidors són idempotents, de manera que un missatge repetit mai no crea un segon enviament ni una segona factura, i els missatges que no es poden lliurar esperen en una cua d’errors per tornar-los a processar.
03
Pas 3: Una línia de temps per comandaSistema
Els esdeveniments d’estat de tots els sistemes (confirmada, preparada, enviada, lliurada, facturada, cobrada) es correlacionen per la referència de negoci en una sola línia de temps. Les regles de fites i de tolerància generen una excepció quan un pas falla, s’endarrereix o no quadra: una falta d’estoc, un preu fora de la tolerància acordada, un lliurament fallit, una factura electrònica rebutjada.
04
Pas 4: Context i propostaAgent d’IA
Per a cada excepció, un agent llegeix el que necessita dels sistemes implicats: la comanda, els nivells d’estoc, l’acord de preus, l’estat del transportista i les condicions del client. Proposa una solució amb el seu raonament i les dades que ha fet servir, com un article substitut, un preu corregit, un lliurament reprogramat o una factura rectificativa.
Via d’excepció: Pas fallit o fora de tolerància
05
Pas 5: Aprovació dins dels llindarsPersona
Una persona d’atenció al client, logística o finances veu l’excepció, l’evidència i la proposta al tauler d’excepcions, i l’aprova, l’edita o la rebutja. L’acció aprovada s’executa per mitjà de l’API del sistema de referència, que publica el canvi com un esdeveniment nou.
Via d’excepció: Pas fallit o fora de tolerància· Torna al pas 2
Punt de control humà
Els agents mai no registren operacions financeres, no canvien preus ni límits de crèdit i no assumeixen compromisos amb clients sense aprovació. Els llindars per tipus d’acció determinen qui aprova, i cada proposta i cada decisió queden registrades.
06
Pas 6: Facturació, aparellament i cobramentSistema
Les factures emeses surten de l’ERP com a factures electròniques estructurades (Facturae, o UBL d’acord amb l’EN 16931) per una plataforma privada d’intercanvi o, quan el destinatari és un organisme públic, per FACe o e-FACT. Les factures de proveïdors s’aparellen amb les comandes de compra i les recepcions de mercaderia, i l’estat de pagament del banc o del proveïdor de pagaments tanca la línia de temps.
07
Pas 7: Revisió del flux i correcció de causesPersona
Les persones responsables dels processos i l’equip d’integració revisen periòdicament les excepcions per motiu, les fallades d’interfície i els conflictes de dades mestres. Corregeixen la causa allà on és, en un registre de dades mestres, una regla de tolerància o una correspondència, en lloc de resoldre una vegada i una altra la mateixa excepció.
Components
Què construiríem
01
Capa d’integració basada en esdeveniments
API i esdeveniments definits primer com a contracte entre l’ERP, el CRM, el comerç electrònic, el magatzem, el transport i les finances, especificats en OpenAPI i AsyncAPI amb sobres CloudEvents, sobre la vostra plataforma d’integració actual o construïts de manera nativa al núvol.
Un sistema de referència i una persona responsable acordats per a cada objecte de dades, regles d’aparellament per a clients, proveïdors i productes, i informes de duplicats i conflictes per a les persones responsables.
Un servei que correlaciona esdeveniments en una sola línia de temps per comanda o petició, aplica regles de fites i de tolerància i mostra el flux i les excepcions a les persones responsables dels processos.
Una cua d’excepcions que mostra el context reunit i la proposta de l’agent, amb accions d’aprovar, editar i rebutjar i amb llindars d’aprovació per tipus d’acció aplicats allà on s’executa l’acció.
Factures en Facturae, en UBL i en les altres sintaxis de l’EN 16931, enviades i rebudes per plataformes privades d’intercanvi (amb Peppol BIS entre les plataformes que el fan servir) o per FACe i e-FACT, validades abans de l’enviament i amb les factures rebutjades adreçades al tauler d’excepcions.
Seguiment de l’estat i alertes per interfície, manuals per a l’equip d’operacions i reprocessament controlat dels missatges fallits, desplegats amb infraestructura com a codi al vostre núvol.
Seguiment i esdeveniments de lliurament dels transportistes
Factures electròniques i respostes d’estat
Extractes bancaris i avisos de pagament
Nucli de la solució
Processos connectats
Sistemes amb què treballa
Vendes, compres i finances de SAP S/4HANAPlataformaSAP
Sales, Service i Commerce Cloud de SalesforcePlataformaSalesforce
Vendes, inventari, compres i comptabilitat d’OdooPlataformaOdoo
Plataformes de comerç electrònic, marketplaces i API de transportistes
Sistemes de gestió de magatzem i de transport
Plataformes de factura electrònica, FACe i e-FACT, bancs i proveïdors de pagament
Gestió d’informació de producte i plataforma de dades
Controls
Controls integrats en el disseny
Límits d’accés
Cada integració i l’agent funcionen amb la seva pròpia identitat de servei a cada sistema, limitada a les operacions d’API que necessiten. L’agent pot llegir de diversos sistemes per reunir context, però només pot escriure per mitjà d’una llista curta d’accions aprovades, executades per l’API del sistema de referència i mai per accés directe a la base de dades.
Revisió humana
Els llindars d’aprovació es fixen per tipus d’acció amb la persona responsable del procés: què només pot proposar l’agent, què aprova una persona de l’equip i què necessita una segona aprovació. Els registres financers, els canvis de preu i de límit de crèdit i els compromisos amb clients sempre esperen una persona. Les accions de baix impacte i reversibles, com tornar a enviar un missatge fallit, es poden executar sense aprovació si la persona responsable hi està d’acord.
Traçabilitat
Cada esdeveniment, proposta, aprovació, rebuig i acció executada es registra amb la referència de la comanda o la petició, amb les dades que ha fet servir l’agent, la versió del model i del prompt i la persona que aprova. Una factura discutida o una queixa d’un client es pot reconstruir pas a pas.
Protecció de dades
Les dades de contacte de clients i proveïdors només arriben als sistemes que les necessiten. La línia de temps desa referències de negoci i estats, no registres complets, i els registres segueixen la conservació que fixeu. El tractament es fa a la regió acordada.
Transparència de la IA
Les propostes de l’agent es marquen com a tals al tauler d’excepcions, amb l’evidència i el raonament al costat. Els sistemes de referència continuen sent la font autoritzada: la línia de temps mostra el que informen i mai no els substitueix.
Indicadors
Què mesuraríem
Acordem aquestes mesures amb vosaltres durant la fase de descoberta i prenem la línia de base dels registres actuals dels sistemes i les interfícies abans de canviar res.
Què mesuraríem
Indicador
Per què és important
Com ho mesuraríem
01Temps de cicle de la comanda
Per què és importantLa mesura que la clientela nota primer, i la que mostra on s’esperen les comandes.
Com ho mesuraríemTemps des de la recepció de la comanda fins al lliurament i fins al cobrament, per canal i societat, segons els esdeveniments de la línia de temps.
02Comandes sense intervenció manual
Per què és importantMostra quina part del flux funciona amb dades netes i normes acordades.
Com ho mesuraríemProporció de comandes i peticions que arriben al cobrament sense cap pas manual ni excepció, segons la línia de temps.
03Excepcions per motiu i temps de resolució
Per què és importantIndica quines causes cal corregir primer i si el tauler d’excepcions dona l’abast.
Com ho mesuraríemVolum d’excepcions per codi de motiu, i temps des de la detecció fins a la resolució executada, segons els registres del tauler.
04Taxa de rebuig de factures electròniques
Per què és importantLes factures rebutjades endarrereixen el cobrament i solen apuntar a errors de dades mestres o de correspondència.
Com ho mesuraríemProporció de factures electròniques enviades i rebudes que es rebutgen, per motiu, segons les respostes de la plataforma d’intercanvi.
05Fallades d’interfície i temps de recuperació
Per què és importantMostra si la capa d’integració és fiable i si les fallades es detecten i es corregeixen ràpidament.
Com ho mesuraríemMissatges fallits per interfície, i temps des de la fallada fins al reprocessament correcte, segons el seguiment de la integració.
06Duplicats i conflictes de dades mestres
Per què és importantLa majoria de les excepcions tenen l’origen en dades que difereixen entre sistemes.
Com ho mesuraríemDuplicats oberts i valors en conflicte per objecte de dades i sistema, segons els informes d’aparellament.
No es fixen objectius abans de disposar d’una mesura de referència.
Desplegament
Com el desplegaríem
Fase 01
Descoberta i mapa del procés
Un procés, com el de la comanda al cobrament d’un canal de venda, i un tipus d’excepció. Fem el mapa dels sistemes, les interfícies, les persones responsables de les dades i la manera com es gestionen avui les excepcions.
Criteris de sortida
Procés, sistemes i responsables de dades identificats
Primer tipus d’excepció i llindars d’aprovació acordats
Línia de base presa dels registres actuals
Fase 02
Integració i línia de temps
API i esdeveniments documentats per als sistemes inclosos, i la línia de temps funcionant al costat de les interfícies actuals sense modificar-les.
Criteris de sortida
Contractes d’esdeveniments publicats i versionats
La línia de temps coincideix amb els sistemes de referència en una mostra de comandes
Reprocessament i manuals d’operació provats
Fase 03
Pilot del tauler d’excepcions
L’agent proposa solucions per al tipus d’excepció triat i les persones aproven totes les propostes. Comparem les propostes amb el que hauria fet el personal.
Criteris de sortida
La qualitat de les propostes compleix els criteris acordats
Llindars i persones aprovadores fixats per tipus d’acció
Traçabilitat revisada per finances i control intern
Fase 04
Ampliació i retirada
Més tipus d’excepció, canals, societats i processos, com el de la compra al pagament, tots sobre els mateixos contractes. Les interfícies punt a punt antigues es desconnecten d’una en una.
Criteris de sortida
Cada flux nou amb els mateixos contractes i el mateix seguiment
Fabricació sota comanda i comandes de recanvis, de l’ERP al magatzem i als transportistes, amb confirmacions de proveïdors i factures electròniques aparellades amb les comandes de compra.
Ordres de treball de manteniment, comandes a contractistes i les seves factures, seguides de la petició al pagament per a gestors d’infraestructures viàries i operadors de transport.
De la compra al pagament amb factures electròniques estructurades entre organismes públics i proveïdors, rebudes per e-FACT o FACe i aparellades amb les comandes i les recepcions abans del pagament.
Exemple il·lustratiu
Un proveïdor de components d’automoció
Situació
Un proveïdor de components d’automoció amb plantes a Espanya i en un altre estat membre ven a fabricants per EDI i al mercat de recanvis per una botiga en línia. Les comandes de recanvis es tornen a teclejar a l’ERP i els transportistes informen per correu dels problemes de lliurament. Com que el seu volum d’operacions supera els 8 milions d’euros, haurà d’emetre factures electròniques a les empreses clients establertes a Espanya a partir del 6 d’octubre del 2027.
Sistema
Les comandes, l’estoc, els enviaments i les factures circulen com a esdeveniments entre l’EDI, la botiga en línia, l’ERP, el sistema de magatzem i els transportistes, i cada comanda té una sola línia de temps. Les factures surten com a factures electròniques estructurades per una plataforma privada d’intercanvi, amb el format que correspon a cada país i client, i el programari de facturació s’adapta a Verifactu.
Control humà
Les faltes d’estoc i els lliuraments fallits arriben a un sol tauler d’excepcions, on un agent proposa un article substitut o una nova data de lliurament. Atenció al client aprova cada proposta; els canvis de preu i les factures rectificatives necessiten l’aprovació de finances.
Què mesuraríem
Proporció de comandes sense intervenció manual per canal i país, excepcions per motiu i temps de resolució, i taxa de rebuig de factures electròniques per país.
Espanya
Un procés, diverses obligacions de facturació
A Espanya, la factura electrònica té dues capes. Amb les administracions, la Llei 25/2013 obliga, entre d’altres, les societats anònimes i limitades i les persones jurídiques sense nacionalitat espanyola a facturar electrònicament pel punt general d’entrada que correspon: FACe per a l’Administració General de l’Estat i e-FACT, del Consorci AOC, per a la Generalitat i les administracions catalanes. Entre empreses, la factura electrònica obligatòria s’aplicarà a partir del 6 d’octubre del 2027 o del 2028, segons el volum d’operacions, i Verifactu afecta els sistemes de facturació a partir del 2027. Peppol BIS és vàlid entre plataformes privades d’intercanvi, però Espanya no té autoritat Peppol.
Les organitzacions que operen en diversos estats membres sovint fan funcionar els mateixos processos de la comanda al cobrament i de la compra al pagament amb instàncies d’ERP, transportistes i bancs diferents, i el paquet de l’IVA en l’era digital fa que la factura electrònica estructurada sigui la norma per als lliuraments B2B intracomunitaris a partir de l’1 de juliol del 2030. Dissenyem una sola capa d’integració amb el format i el canal de cada país darrere dels mateixos esdeveniments, de manera que una obligació nova vol dir un connector nou, no un procés nou.
El Reglament de dades, aplicable des del 12 de setembre del 2025, fixa normes per canviar de servei de tractament de dades, i per això mantenim portables els contractes d’esdeveniments i les exportacions de dades. Els agents del tauler d’excepcions es dissenyen tenint en compte el Reglament d’intel·ligència artificial (RIA), i les integracions incorporen accessos registrats i components documentats per als clients que s’han de preparar per a la seguretat de la cadena de subministrament de la Directiva NIS2 (a Espanya, la transposició és encara un avantprojecte de llei, situació a 6 de novembre del 2026).
No. L’ERP, el CRM, la botiga en línia i el sistema de magatzem fan cadascun la seva feina. Integrem al voltant d’aquests sistemes de referència, acordem quin sistema és responsable de cada dada i donem al procés una sola línia de temps per a tots. Quan un sistema de comandes o un ERP antic bloqueja el canvi, la solució Modernització de sistemes heretats el posa primer darrere d’API.
02Substituïu el nostre middleware d’integració?
No, si fa la seva feina. Construïm sobre la plataforma d’integració o el gestor de missatges que ja feu servir, i hi afegim contractes, seguiment i reprocessament on falten. Si no n’hi ha cap, construïm de manera nativa al núvol. Vegeu el servei Integracions i API.
03Els agents poden actuar pel seu compte?
Només dins dels llindars que acordeu per a cada tipus d’acció, i només en accions de baix impacte que es poden desfer, com tornar a enviar un missatge fallit. Els registres financers, els preus, els límits de crèdit i els compromisos amb clients sempre necessiten una persona. Llegiu on necessiten aprovació humana els agents d’IA.
04Com hi encaixa la factura electrònica obligatòria?
A Espanya, la factura electrònica obligatòria entre empresaris i professionals s’aplicarà a partir del 6 d’octubre del 2027 a les empreses amb un volum d’operacions superior a 8 milions d’euros l’any natural anterior, i a partir del 6 d’octubre del 2028 a la resta, per plataformes privades d’intercanvi o per la solució pública de facturació electrònica de l’Agència Tributària. Verifactu és una obligació a part sobre els sistemes informàtics de facturació, a partir del 2027. A escala de la UE, el paquet de l’IVA en l’era digital fa que la factura electrònica estructurada sigui la norma per als lliuraments B2B intracomunitaris a partir de l’1 de juliol del 2030. Tractem la factura electrònica com un esdeveniment més del procés: s’emet des de l’ERP, s’envia pel canal que correspon i, si es rebutja, es gestiona al tauler d’excepcions. Vegeu la nostra guia de la factura electrònica.
05Com eviteu una altra xarxa fràgil d’enllaços punt a punt?
Els sistemes publiquen i consumeixen esdeveniments i API documentats per mitjà d’una sola capa, no per enllaços directes entre ells. Els contractes es versionen, els consumidors són idempotents, els missatges fallits es poden tornar a processar i cada flux té una persona responsable. Un canal nou se subscriu als esdeveniments existents en lloc d’afegir un enllaç a cada sistema.
06Com és un primer abast?
Un procés i un tipus d’excepció, per exemple de la comanda al cobrament per a un canal de venda, amb les faltes d’estoc com a primera excepció. Així es proven els esdeveniments, la línia de temps i el flux d’aprovació abans d’afegir-hi més. Vegeu el nostre enfocament.
Parlem dels vostres fluxos de comandes i factures
Trieu un procés i els països on funciona. Farem amb vosaltres el mapa dels sistemes, les interfícies i les excepcions i us proposarem una primera versió que funcioni per a totes les vostres societats.