Cada pedido nunha única liña temporal, da entrada á factura cobrada.
Do pedido ao cobro, da compra ao pagamento e da solicitude de servizo á factura, os procesos atravesan o ERP, o CRM, o comercio electrónico, o almacén, o transporte e os sistemas financeiros. Conectámolos con API e eventos documentados, damos a cada pedido un único estado en todos eses sistemas e enviamos cada excepción a un axente que prepara unha solución para que a aprobe unha persoa.
Para empresas que venden, compran e facturan desde España, con Verifactu e a factura electrónica entre empresas no calendario de 2027 e 2028.
Planificación da cadea de subministración e loxística
Equipos de contas a pagar e a cobrar
Integración e operacións de TI
Fluxo de traballo ilustrativo
01Rexistrar o evento unha vezSistema
02Distribuír por API e eventosSistema
03Unha liña temporal por pedidoSistema
04Reunir contexto e propoñerAxente de IA
05Aprobar dentro dos limiaresPersoa
06Facturar, cotexar e cobrarSistema
07Revisar o fluxo e corrixir as causasPersoa
Un pedido de venda, un pedido de compra ou unha solicitude de servizo rexístrase unha soa vez no seu sistema de referencia e distribúese aos demais sistemas mediante API e eventos documentados. Os eventos de estado constrúen unha liña temporal por pedido. Cando un paso falla ou sae da tolerancia, un axente reúne o contexto e propón unha solución, que unha persoa aproba antes de que se execute no sistema de referencia. As facturas intercámbianse e cotéxanse como facturas electrónicas estruturadas, e as persoas responsables dos procesos revisan o fluxo e o estado das interfaces.
Antes e despois
Que cambia nas operacións diarias
Hoxe
Co sistema
Hoxe
Hoxe: Escribir de novo en cada traspaso
Un pedido recibido na tenda en liña ou polo equipo comercial vólvese escribir no ERP, e os datos de entrega e de factura cópianse a man nos sistemas de almacén, transporte e finanzas.
Co sistema
Co sistema: Introducido unha vez, usado en todas partes
Cada pedido, entrega e factura créase no sistema ao que pertence e publícase como evento. Os demais sistemas subscríbense a el en lugar de volvelo escribir.
Hoxe
Hoxe: O estado de onte
As interfaces por lotes nocturnas fan que atención á clientela, planificación e finanzas vexan cada unha un estado distinto e desactualizado do mesmo pedido. Un cliente que pregunta onde está unha entrega recibe unha chamada horas despois.
Co sistema
Co sistema: Un único estado actual
Cada pedido ou solicitude ten unha liña temporal construída cos eventos de todos os sistemas polos que pasa. Atención á clientela, planificación e finanzas ven os mesmos feitos, e tamén un asistente de atención ao público que responda preguntas sobre o estado.
Hoxe
Hoxe: Excepcións resoltas no correo
As roturas de stock, as diferenzas de prezo, as entregas falladas e as facturas electrónicas rexeitadas resólvense por correo e en follas de cálculo, e despois ninguén sabe quen decidiu que.
Co sistema
Co sistema: As excepcións chegan cunha proposta
Un axente reúne os datos de cada excepción e propón unha solución. Unha persoa apróbaa, edítaa ou rexéitaa nun único posto de excepcións, e a decisión queda rexistrada.
Hoxe
Hoxe: Datos mestres que non coinciden
O mesmo cliente, provedor, produto ou prezo existe en varios sistemas con valores distintos, e ninguén é responsable de cal é o correcto.
Co sistema
Co sistema: Unha persoa responsable por obxecto de datos
Clientes, provedores, produtos e prezos teñen cada un un sistema de referencia acordado e unha persoa responsable. Os duplicados e os conflitos comunícanselle a esa persoa, en vez de corrixirse en silencio nos sistemas posteriores.
Hoxe
Hoxe: Cada cambio engade unha interface
Unha nova canle de venda, un marketplace ou unha nova sociedade suman outra conexión punto a punto. Verifactu e a factura electrónica entre empresas engaden ademais formatos e plataformas a cada proceso.
Co sistema
Co sistema: As conexións novas reutilizan os mesmos contratos
Unha nova canle, sociedade ou plataforma de factura electrónica conéctase unha vez a API e eventos documentados, en lugar de a cada sistema por separado.
Fluxo de traballo
Como funciona o fluxo de traballo
Cando os datos están limpos, o camiño principal non require traballo manual. Cando un pedido, unha entrega ou unha factura se desvía, o ciclo de excepcións lévao a unha persoa coas evidencias e unha proposta, e a corrección aprobada volve pola mesma capa de integración.
Fluxo de traballo ilustrativo
7 pasos · 1 punto de control humano
Lenda
Sistema
Axente de IA
Persoa
Punto de control humano
Vía de excepción
Operacións conectadas: fluxo ilustrativo con ciclo de excepcións
Ler o diagrama como texto
O camiño principal vai do rexistro dun evento de negocio unha soa vez no seu sistema de referencia, pasando pola súa distribución aos demais sistemas mediante API e eventos e pola construción dunha liña temporal por pedido, ata a facturación, o cotexo e o cobro. Remata coas persoas responsables dos procesos revisando o fluxo e corrixindo as causas das excepcións.
Cando un paso falla, se atrasa ou sae da tolerancia, a excepción abandona o camiño principal despois do paso da liña temporal. Un axente reúne o contexto e propón unha solución, e unha persoa apróbaa, edítaa ou rexéitaa. A acción aprobada execútase no sistema de referencia e volve ao paso de distribución como un evento novo.
O paso de aprobación é o punto de control humano: ningunha contabilización financeira, ningún cambio de prezo ou de límite de crédito e ningún compromiso cun cliente se fai sen unha persoa.
01
Paso 1: Rexistrar o evento unha vezSistema
Un pedido de venda da tenda en liña, dun marketplace, por EDI ou do equipo comercial, un pedido de compra ou unha solicitude de servizo créase no sistema ao que pertence. Ese sistema publica un evento de negocio nun envoltorio CloudEvents, descrito nun contrato AsyncAPI. Os pedidos en papel ou PDF e as facturas de provedores pasan antes polo procesamento de documentos.
02
Paso 2: Distribuír por API e eventosSistema
A capa de integración entrega o evento aos sistemas de almacén, transporte, finanzas e CRM mediante as súas API documentadas (OpenAPI). Os consumidores son idempotentes, de modo que unha mensaxe repetida nunca crea un segundo envío nin unha segunda factura, e as mensaxes que non se poden entregar agardan nunha cola de erros para volver procesarse.
03
Paso 3: Unha liña temporal por pedidoSistema
Os eventos de estado de cada sistema (confirmado, preparado, expedido, entregado, facturado, cobrado) correlaciónanse pola referencia de negocio nunha única liña temporal. As regras de fitos e tolerancias abren unha excepción cando un paso falla, se atrasa ou non coincide: unha rotura de stock, un prezo fóra da tolerancia acordada, unha entrega fallada, unha factura electrónica rexeitada.
04
Paso 4: Reunir contexto e propoñerAxente de IA
Para cada excepción, un axente le o que precisa dos sistemas implicados: o pedido, o stock, o acordo de prezos, o estado do transportista e as condicións do cliente. Propón unha solución co seu razoamento e os datos que usou, como un artigo substituto, un prezo corrixido, unha nova data de entrega ou unha factura rectificativa.
Vía de excepción: Paso fallado ou fóra de tolerancia
05
Paso 5: Aprobar dentro dos limiaresPersoa
Unha persoa de atención á clientela, loxística ou finanzas ve a excepción, as evidencias e a proposta no posto de excepcións, e apróbaa, edítaa ou rexéitaa. A acción aprobada execútase a través da API do sistema de referencia, que publica o cambio como un evento novo.
Vía de excepción: Paso fallado ou fóra de tolerancia· Volve ao paso 2
Punto de control humano
Os axentes nunca contabilizan operacións financeiras, cambian prezos ou límites de crédito nin adquiren compromisos coa clientela sen aprobación. Os limiares por tipo de acción determinan quen aproba, e cada proposta e cada decisión quedan rexistradas.
06
Paso 6: Facturar, cotexar e cobrarSistema
As facturas emitidas saen do ERP como facturas electrónicas estruturadas (Facturae ou UBL conforme á EN 16931) a través dunha plataforma de factura electrónica, e as dirixidas a organismos públicos van ao seu punto xeral de entrada. As facturas recibidas de provedores cotéxanse cos pedidos de compra e as entradas de mercadoría, e o estado do pagamento que informa o banco ou o provedor de pagamentos pecha a liña temporal.
07
Paso 7: Revisar o fluxo e corrixir as causasPersoa
As persoas responsables dos procesos e o equipo de integración revisan cun ritmo fixo as excepcións por motivo, os fallos das interfaces e os conflitos de datos mestres. Corrixen a causa onde está, nun dato mestre, nunha regra de tolerancia ou nunha correspondencia, en vez de resolver unha e outra vez a mesma excepción.
Compoñentes
O que construiriamos
01
Capa de integración baseada en eventos
API e eventos definidos primeiro como contrato entre ERP, CRM, comercio electrónico, almacén, transporte e finanzas, especificados en OpenAPI e AsyncAPI con envoltorios CloudEvents, sobre a súa plataforma de integración actual ou construídos de forma nativa na nube.
Un sistema de referencia e unha persoa responsable acordados por obxecto de datos, regras de coincidencia para clientes, provedores e produtos, e informes de duplicados e conflitos para quen os xestiona.
Un servizo que correlaciona os eventos nunha liña temporal por pedido ou solicitude, aplica regras de fitos e tolerancias e mostra o fluxo e as excepcións ás persoas responsables dos procesos.
Unha cola de excepcións co contexto reunido e a proposta do axente, con accións para aprobar, editar e rexeitar e limiares de aprobación por tipo de acción aplicados no punto onde se executa a acción.
Facturas en Facturae e en UBL conforme á EN 16931, enviadas e recibidas a través dunha plataforma de factura electrónica e validadas antes do envío, coas facturas rexeitadas encamiñadas ao posto de excepcións e os sistemas de facturación preparados para Verifactu.
Seguimento e alertas do estado de cada interface, manuais de operación para o equipo de operacións e reprocesamento controlado das mensaxes falladas, implantado con infraestrutura como código no seu contorno de nube.
Solicitudes de servizo e partes de traballo de campo
Seguimento e eventos de entrega dos transportistas
Facturas electrónicas e respostas de estado
Extractos bancarios e avisos de pagamento
Núcleo da solución
Operacións conectadas
Sistemas cos que traballa
SAP S/4HANA para vendas, compras e finanzasPlataformaSAP
Salesforce Sales, Service e Commerce CloudPlataformaSalesforce
Odoo para vendas, inventario, compras e contabilidadePlataformaOdoo
Plataformas de comercio electrónico, marketplaces e API de transportistas
Sistemas de xestión de almacén e de transporte
Plataforma de factura electrónica, bancos e provedores de pagamento
Xestión da información de produto e plataforma de datos
Controis
Controis previstos desde o deseño
Límites de acceso
Cada integración e o axente funcionan coa súa propia identidade de servizo en cada sistema, limitada ás operacións de API que precisan. O axente pode ler en varios sistemas para reunir contexto, pero só pode escribir mediante unha lista curta de accións aprobadas, executadas pola API do sistema de referencia e nunca con acceso directo á base de datos.
Revisión humana
Os limiares de aprobación fíxanse por tipo de acción coa persoa responsable do proceso: o que o axente só pode propoñer, o que aproba unha persoa do equipo e o que precisa unha segunda aprobación. As contabilizacións financeiras, os cambios de prezos e de límites de crédito e os compromisos coa clientela agardan sempre por unha persoa. As accións de baixo impacto e reversibles, como volver enviar unha mensaxe fallada, poden executarse sen aprobación se a persoa responsable o acepta.
Auditabilidade
Cada evento, proposta, aprobación, rexeitamento e acción executada rexístrase coa referencia do pedido ou da solicitude, cos datos que usou o axente, a versión do modelo e das instrucións e a persoa que aprobou. Unha factura en disputa ou unha reclamación dun cliente pódense seguir paso a paso.
Protección de datos
Os datos de contacto de clientes e provedores só chegan aos sistemas que os precisan. A liña temporal garda referencias de negocio e estados, non rexistros completos, e os rexistros de actividade seguen o prazo de conservación que vostede fixe. O tratamento queda na rexión acordada.
Transparencia da IA
As propostas do axente aparecen marcadas como tales no posto de excepcións, coas evidencias e o razoamento ao lado. Os sistemas de referencia seguen tendo a última palabra: a liña temporal mostra o que eles informan e nunca os substitúe.
Indicadores
O que mediriamos
Acordamos estes indicadores con vostede durante o descubrimento e tomamos a liña de base dos rexistros actuais dos seus sistemas e interfaces antes de cambiar nada.
O que mediriamos
Indicador
Por que é importante
Como o mediriamos
01Tempo do ciclo do pedido
Por que é importanteO indicador que a clientela nota primeiro, e o que mostra onde agardan os pedidos.
Como o mediriamosTempo desde a recepción do pedido ata a entrega e ata o cobro, por canle e por sociedade, a partir dos eventos da liña temporal.
02Pedidos sen intervención manual
Por que é importanteMostra que parte do fluxo funciona con datos limpos e regras acordadas.
Como o mediriamosProporción de pedidos e solicitudes que chegan ao cobro sen ningún paso manual nin excepción, a partir da liña temporal.
03Excepcións por motivo e tempo de resolución
Por que é importanteIndica que causas convén corrixir primeiro e se o posto de excepcións dá abasto.
Como o mediriamosVolume de excepcións por código de motivo e tempo desde a detección ata a solución executada, a partir dos rexistros do posto de excepcións.
04Taxa de rexeitamento de facturas electrónicas
Por que é importanteAs facturas rexeitadas atrasan o cobro e adoitan apuntar a erros de datos mestres ou de correspondencias.
Como o mediriamosProporción de facturas electrónicas enviadas e recibidas que se rexeitan, por motivo, a partir das respostas da plataforma de factura electrónica.
05Fallos das interfaces e tempo de recuperación
Por que é importanteMostra se a capa de integración é fiable e se os fallos se detectan e se corrixen axiña.
Como o mediriamosMensaxes falladas por interface e tempo desde o fallo ata o reprocesamento correcto, a partir do seguimento da integración.
06Duplicados e conflitos de datos mestres
Por que é importanteA maioría das excepcións remóntanse a datos que difiren entre sistemas.
Como o mediriamosDuplicados abertos e valores en conflito por obxecto de datos e por sistema, a partir dos informes de coincidencia.
Non fixamos obxectivos antes de dispor dunha liña de base.
Implantación
Como o implantariamos
Fase 01
Descubrimento e mapa do proceso
Un proceso, como do pedido ao cobro nunha canle de venda, e un tipo de excepción. Describimos os sistemas, as interfaces, as persoas responsables dos datos e como se xestionan hoxe as excepcións.
Criterios de saída
Proceso, sistemas e persoas responsables dos datos identificados
Primeiro tipo de excepción e limiares de aprobación acordados
Liña de base tomada dos rexistros actuais
Fase 02
Integración e liña temporal
API e eventos documentados para os sistemas incluídos, e a liña temporal funcionando xunto ás interfaces existentes sen modificalas.
Criterios de saída
Contratos de eventos publicados e versionados
A liña temporal coincide cos sistemas de referencia nunha mostra de pedidos
Reprocesamento e manuais de operación probados
Fase 03
Piloto do posto de excepcións
O axente propón solucións para o tipo de excepción escollido e as persoas aproban todas as propostas. Comparamos as propostas co que faría o persoal.
Criterios de saída
A calidade das propostas cumpre os criterios acordados
Limiares e persoas aprobadoras fixados por tipo de acción
Rastro de auditoría revisado por finanzas e control interno
Fase 04
Ampliar e retirar
Máis tipos de excepción, canles, sociedades e procesos, como da compra ao pagamento, todos cos mesmos contratos. As antigas conexións punto a punto apáganse unha a unha.
Criterios de saída
Cada fluxo novo cos mesmos contratos e o mesmo seguimento
Pedidos baixo encarga e de recambios do ERP ao almacén e aos transportistas, coas confirmacións de provedores e as facturas electrónicas cotexadas cos pedidos de compra.
Solicitudes de conexión e de instalación seguidas desde a orde de traballo e a visita de campo ata a factura, e materiais comprados conforme a acordos marco.
Ordes de traballo de mantemento, pedidos a contratistas e as súas facturas, seguidos desde a solicitude ata o pagamento para as entidades xestoras de infraestruturas.
Da compra ao pagamento con facturas electrónicas estruturadas cara a organismos públicos e desde eles, a través de FACe ou do punto de entrada autonómico, cotexadas cos pedidos e as recepcións antes do pagamento.
Exemplo ilustrativo
Do pedido ao cobro nun provedor de automoción
Situación
Un provedor de compoñentes de automoción recibe pedidos por EDI e por correo de clientes industriais en España e noutros países europeos, e serve desde dous almacéns. Os pedidos por correo vólvense escribir no ERP, os transportistas avisan das incidencias por correo e o sistema de facturación aínda non está adaptado a Verifactu nin á factura electrónica entre empresas.
Sistema
Pedidos, stock, envíos e facturas circulan como eventos entre o ERP, o sistema de almacén e os transportistas, e cada pedido ten unha liña temporal. As facturas saen do ERP como facturas electrónicas estruturadas, cos requisitos de Verifactu, a través dunha plataforma de factura electrónica.
Control humano
As roturas de stock e as entregas falladas chegan a un único posto de excepcións, onde un axente propón unha nova data de entrega ou un envío parcial. Atención á clientela aproba cada proposta; os cambios de prezo e as facturas rectificativas precisan a aprobación de finanzas.
O que mediriamos
Proporción de pedidos sen intervención manual por cliente e por canle, excepcións por motivo e tempo de resolución, e taxa de rexeitamento de facturas electrónicas.
España
Un proceso, coas datas de España
En España, os sistemas de facturación deben cumprir Verifactu antes do 1 de xaneiro de 2027 (imposto sobre sociedades) ou do 1 de xullo de 2027 (o resto). A factura electrónica entre empresas será obrigatoria desde o 6 de outubro de 2027 para as empresas que superaron 8 millóns de euros de volume de operacións no ano anterior, e desde o 6 de outubro de 2028 para as demais. As facturas aos organismos públicos van por FACe ou polo punto de entrada de cada administración, como o SEF da Xunta de Galicia. Cada formato queda detrás dos mesmos eventos de integración.
Tendo en conta o Regulamento de datos, mantemos portables os contratos de eventos; os axentes deséñanse co Regulamento de IA en mente. A transposición da NIS2 en España segue pendente, pero as integracións xa inclúen accesos rexistrados e compoñentes documentados para a seguridade da cadea de subministración.
Non. O seu ERP, o seu CRM, a súa tenda en liña e o seu sistema de almacén fan cada un o seu traballo. Integramos arredor deses sistemas de referencia, acordamos que sistema é dono de que datos e damos ao proceso unha única liña temporal entre todos eles. Se un sistema antigo de pedidos ou un ERP antigo bloquea o cambio, a modernización de sistemas herdados sitúao primeiro detrás de API.
02Substitúen o noso middleware de integración?
Non, se cumpre a súa función. Construímos sobre a plataforma de integración ou o intermediario de mensaxes que xa ten, e engadimos contratos, seguimento e reprocesamento onde faltan. Se non hai ningún, construímos de forma nativa na nube. Máis información en Integracións e API.
03Poden actuar os axentes pola súa conta?
Só dentro dos limiares que se acorden por tipo de acción, e só en accións de baixo impacto que se poidan desfacer, como volver enviar unha mensaxe fallada. As contabilizacións financeiras, os prezos, os límites de crédito e os compromisos coa clientela precisan sempre dunha persoa. Lea onde precisan aprobación humana os axentes de IA.
04Como encaixan Verifactu e a factura electrónica entre empresas?
En España, os sistemas de facturación deben cumprir os requisitos de Verifactu antes do 1 de xaneiro de 2027 no caso dos contribuíntes do imposto sobre sociedades, e antes do 1 de xullo de 2027 no resto. A factura electrónica entre empresas será obrigatoria desde o 6 de outubro de 2027 para as que superaron 8 millóns de euros de volume de operacións no ano anterior, e desde o 6 de outubro de 2028 para as demais. Na UE, o paquete do IVE na era dixital (ViDA) fai da factura electrónica estruturada a opción predeterminada nas entregas B2B intracomunitarias desde o 1 de xullo de 2030. Tratamos a factura electrónica como un evento máis do proceso: emítese desde o ERP, envíase a través da plataforma de factura electrónica e xestiónase no posto de excepcións se se rexeita. Consulte a nosa guía da factura electrónica entre empresas.
05Como evitan outra rede fráxil de conexións punto a punto?
Os sistemas publican e consumen eventos e API documentados a través dunha única capa, non mediante conexións directas entre eles. Os contratos están versionados, os consumidores son idempotentes, as mensaxes falladas pódense volver procesar e cada fluxo ten unha persoa responsable. Unha canle nova subscríbese aos eventos existentes en lugar de engadir unha conexión con cada sistema.
06Como é un primeiro alcance?
Un proceso e un tipo de excepción, por exemplo do pedido ao cobro nunha canle de venda, coas roturas de stock como primeira excepción. Serve para probar os eventos, a liña temporal e o fluxo de aprobación antes de engadir máis. Lea máis sobre o noso enfoque.
Fálenos dos seus fluxos de pedidos e facturas
Escolla un proceso e as sociedades nas que funciona. Describiremos con vostede os sistemas, as interfaces e as excepcións e propoñerémoslle unha primeira versión.