modern-sap-lab: intermediación comercial con Clean Core
Durante los próximos días voy a construir un laboratorio SAP alrededor de un caso de negocio realista: un sistema de intermediación comercial entre distintas empresas que venden productos y los clientes de esas empresas.
El objetivo no es construir otro ERP ni reproducir funcionalidades que SAP ya resuelve. Quiero utilizar el ejercicio para practicar de nuevo ABAP Cloud, CDS, RAP, CAP, SAP Integration Suite y BTP, pero sobre todo para razonar qué debe implementarse, dónde debe vivir y por qué.
El punto de partida será Clean Core: SAP S/4HANA seguirá resolviendo aquello que pertenece naturalmente al ERP de la empresa intermediaria; la lógica específica de intermediación se mantendrá desacoplada.
El escenario
La empresa intermediaria trabaja con distintos Principal —una fábrica, un mayorista, un distribuidor u otra empresa que comercializa directamente sus productos a sus clientes—.
La relación básica será:
Cliente final
│
│ compra mercancía
▼
Principal
│
│ paga comisión
▼
Empresa intermediariaEl Principal es proveedor del cliente final, pero para la empresa intermediaria es un cliente, porque recibe de nosotros un servicio de intermediación y nos paga una comisión.
Qué papel juega SAP
SAP S/4HANA será el ERP de la empresa intermediaria.
Por tanto, deberá encargarse de aquello que ya pertenece naturalmente al ERP:
- maestro de clientes de nuestra empresa;
- facturación;
- fiscalidad;
- condiciones de pago;
- contabilización;
- cuentas a cobrar;
- integración financiera.
No quiero introducir en el núcleo de S/4 toda la lógica específica de intermediación.
Los catálogos de los Principal, sus tarifas, sus ofertas, los pedidos realizados por sus clientes, los albaranes y el cálculo de las comisiones pertenecen al proceso de intermediación y deben evolucionar sin obligarnos a modificar el core del ERP.
Por qué Clean Core
Mi experiencia previa mejorando y desacoplando aplicaciones legacy hace que Clean Core no me parezca sólo una recomendación tecnológica.
El problema de fondo es conocido: cuanto más conocimiento específico del negocio se incrusta dentro del núcleo de una plataforma, más difícil resulta actualizarla, sustituirla o evolucionarla.
En este ejercicio intentaré mantener una regla sencilla:
SAP sólo debe conocer aquello que necesita conocer.
Por ejemplo, los artículos que vende un Principal no serán materiales SAP.
La empresa intermediaria no los compra, no los almacena y no los vende. No existe, por tanto, una razón funcional para convertirlos en materiales de nuestro ERP.
El proceso que vamos a modelar
1. Alta de un Principal
Cada Principal tendrá una relación comercial con la empresa intermediaria.
Para comenzar simplificaremos el modelo suponiendo una comisión general por Principal.
Más adelante podría permitirse que determinados productos tuvieran una comisión diferente, pero no es necesario para el primer MVP.
2. Catálogo propio
Cada Principal mantiene su propio catálogo de productos.
Por ejemplo:
Principal: ACME
Referencia: XZ-150
Descripción: Motor industrial 150 WEste producto pertenece al catálogo de ACME.
No tiene por qué existir ninguna correspondencia con un material de SAP.
3. Tarifas
Cada Principal comunica las tarifas de sus productos.
Una tarifa tendrá una fecha de inicio y, opcionalmente, una fecha de fin.
Por ejemplo:
Tarifa A
Desde: 01-01-2026
Hasta: 30-09-2026y:
Tarifa B
Desde: 01-10-2026
Hasta: nueva ordenLas tarifas podrán recibirse con antelación.
Si hoy recibimos una tarifa que empieza el 1 de enero del año siguiente, podremos cargarla inmediatamente sin que afecte a los pedidos actuales.
La tarifa aplicable será siempre la correspondiente a la fecha del pedido, no la última tarifa recibida.
Tarifas futuras y vigencia
Supongamos que existe:
Tarifa A
01-01-2026 → sin fecha de finy recibimos:
Tarifa B
01-10-2026 → sin fecha de finAl publicar la nueva tarifa, la situación deberá quedar así:
Tarifa A
01-01-2026 → 30-09-2026
Tarifa B
01-10-2026 → sin fecha de finHasta el 30 de septiembre se continuará utilizando la tarifa A.
Los pedidos realizados desde el 1 de octubre utilizarán la tarifa B.
Para una fecha concreta sólo podrá existir una tarifa aplicable. Los solapamientos estarán prohibidos.
También será válido que no exista ninguna tarifa vigente. Si una tarifa termina hoy y no existe una tarifa posterior, mañana ese Principal no tendrá catálogo disponible para nuevos pedidos.
Ofertas
Una oferta no será una tarifa temporal.
Será un descuento adicional con su propio intervalo de vigencia.
Por ejemplo:
Oferta
20-09-2026 → 10-10-2026
Producto XZ-150
Descuento adicional: 5 %La oferta podrá atravesar un cambio de tarifa.
20-09 → 30-09
Tarifa A + oferta
01-10 → 10-10
Tarifa B + ofertaAsí mantenemos separados dos conceptos de negocio distintos:
- la tarifa determina el precio normal vigente;
- la oferta introduce una condición temporal adicional.
Formación del precio
Para cada producto y fecha determinaremos:
Precio de tarifa
- descuento 1
- descuento 2
- descuento 3
- descuento de oferta
= precio netoLos descuentos se aplicarán sucesivamente.
Por ejemplo:
Precio tarifa: 100 €
Descuento 1: 10 %
Oferta: 5 %Resultado:
100 × 0,90 × 0,95 = 85,50 €Creación del pedido
El pedido no nace en SAP.
El cliente final entra en la aplicación de intermediación, selecciona un Principal y consulta el catálogo disponible para la fecha del pedido.
Después selecciona productos y cantidades.
Al guardar el pedido, el sistema conservará una fotografía económica de las condiciones aplicadas:
- referencia y descripción;
- precio de tarifa;
- descuentos;
- oferta;
- precio neto;
- comisión aplicable.
Si una tarifa cambia posteriormente, el pedido histórico no se recalculará.
Entrega y albarán
El Principal sirve directamente la mercancía al cliente final.
La empresa intermediaria no compra, almacena ni manipula esos productos.
Después, el Principal remite una copia del albarán.
Ese albarán no se considerará automáticamente definitivo.
El cliente deberá confirmar lo realmente recibido.
Podremos tener, por ejemplo:
Cantidad pedida: 10
Cantidad declarada por Principal: 8
Cantidad confirmada por cliente: 7La aplicación deberá conservar la discrepancia y permitir su corrección.
Pedidos parcialmente servidos
Un pedido podrá quedar parcialmente servido.
Las cantidades pendientes podrán:
- quedar pendientes para una entrega posterior;
- o descartarse.
No intentaremos resolver desde el primer día todas las casuísticas administrativas posibles.
El modelo sólo necesita poder distinguir correctamente:
cantidad pedida
cantidad servida
cantidad pendienteComisión
La comisión nunca se calculará sobre lo pedido.
Se calculará exclusivamente sobre la mercancía realmente servida y confirmada.
Por ejemplo:
Precio neto: 94,05 €
Cantidad confirmada: 7
Comisión: 5 %Base:
7 × 94,05 = 658,35 €Comisión:
658,35 × 5 % = 32,92 €Liquidación
Los albaranes confirmados se irán acumulando hasta el cierre correspondiente.
En el cierre:
- se seleccionan los albaranes confirmados todavía no liquidados;
- se calcula la comisión;
- se genera una liquidación;
- los albaranes incluidos quedan cerrados a efectos de comisión;
- la liquidación se transmite a SAP para facturación.
La aplicación de intermediación determinará qué debe facturarse.
SAP determinará cómo debe facturarse y contabilizarse.
Facturación en SAP
La empresa intermediaria factura su servicio al Principal.
No construiremos un motor de facturación paralelo.
SAP seguirá siendo responsable de:
- factura;
- impuestos;
- condiciones de pago;
- vencimiento;
- contabilización;
- FI.
Nuestro módulo enviará únicamente la información necesaria para que SAP facture el servicio de intermediación.
Arquitectura inicial
La primera hipótesis de arquitectura será:
Principal / sistemas externos
│
▼
SAP Integration Suite
│
▼
SAP BTP ABAP Environment
ABAP Cloud + RAP
│
├──────────────► CAP / aplicación externa
│
└──────────────► SAP S/4HANA
Billing / FILa distribución inicial de responsabilidades será la siguiente.
SAP BTP ABAP Environment
Será el candidato a system of record del proceso de intermediación:
- Principal;
- productos;
- tarifas;
- ofertas;
- pedidos;
- albaranes;
- comisiones;
- liquidaciones.
CAP
Lo utilizaremos para exponer servicios orientados a usuarios externos.
Por ejemplo:
- consultar Principal;
- consultar catálogo;
- crear pedidos;
- consultar pedidos;
- confirmar albaranes.
CAP no duplicará el dominio de ABAP.
SAP Integration Suite
Se utilizará como capa de integración:
- REST/JSON;
- SFTP;
- CSV;
- transformación de formatos;
- routing;
- seguridad;
- integración con SAP.
SAP S/4HANA
Seguirá siendo responsable de:
- Business Partner / cliente;
- facturación;
- condiciones de pago;
- fiscalidad;
- FI.
Integración con sistemas externos
Los Principal no tienen por qué utilizar SAP.
Por eso el dominio no dependerá del protocolo mediante el que llegue la información.
Implementaremos inicialmente dos vías:
REST/JSON
Para sistemas modernos.
Por ejemplo:
POST /tariffs
POST /offers
POST /delivery-notesCSV mediante SFTP
Para integraciones batch más tradicionales.
Ambos caminos deberán producir el mismo modelo canónico.
El dominio de negocio no debería saber si una tarifa llegó mediante REST, CSV, XML o cualquier otro mecanismo.
Usuarios
Tendremos tres perfiles diferentes.
Administrativo interno
Gestionará el backoffice mediante RAP/Fiori.
Cliente final
No tendrá que entrar en S/4.
Utilizará una aplicación externa para consultar catálogos, crear pedidos y confirmar entregas.
Principal
Inicialmente se integrará como sistema técnico mediante API o intercambio de ficheros.
No necesita un usuario humano dentro de SAP.
Qué vamos a construir
El desarrollo se dividirá en pequeños bloques.
M01 Principal Management
M02 Principal Products
M03 Tariffs
M04 Offers
M05 Pricing
M06 Orders
M07 CAP Customer Service
M08 Integration Suite
M09 Delivery Notes
M10 Settlements
M11 Integración con S/4HANA
M12 Seguridad, pruebas y demo finalCada módulo tendrá que poder explicarse de forma independiente.
La regla será:
Un módulo, una competencia, una demo y una explicación de tres minutos.
Qué no vamos a hacer
El ejercicio no pretende convertirse en un producto comercial completo.
Inicialmente quedarán fuera:
- devoluciones;
- facturas rectificativas;
- comisiones diferentes por artículo;
- múltiples monedas complejas;
- fiscalidad propia;
- EDI;
- AS2;
- Event Mesh;
- IA;
- multitenancy;
- motores genéricos de reglas;
- algoritmos sofisticados para casos excepcionales de vigencia.
Algunas de estas capacidades podrían añadirse posteriormente.
Pero añadir complejidad no es el objetivo.
Qué quiero demostrar
El propósito del laboratorio no es simplemente mostrar que puedo crear una CDS View, un Business Object RAP o un servicio CAP.
Quiero trabajar sobre un problema empresarial y demostrar el proceso completo:
- entender la necesidad;
- identificar las reglas;
- separar responsabilidades;
- decidir qué debe resolver SAP estándar;
- decidir qué debe ser desarrollo propio;
- mantener Clean Core;
- diseñar integraciones desacopladas;
- probar las decisiones;
- y justificar técnicamente por qué se ha elegido cada solución.
La tecnología es una parte del ejercicio.
La otra parte —y probablemente la más importante— será tomar buenas decisiones antes de empezar a programar.
El siguiente paso será construir el primer bloque: Principal Management con ABAP Cloud, CDS y RAP.