Antes de escribir código SAP pasé ocho años en una planta cárnica gestionando recepción, lotes, caducidades y trazabilidad, y participé durante dos años en la implantación del ERP de la fábrica formando a 40–50 operarios de planta.

Cuando un requerimiento habla de entradas de mercancía o de diferencias de inventario, no necesito que me lo traduzcan.

Business object RAP managed con draft sobre un árbol de composición de tres niveles —entrada → posición → lote— con 6 determinations, 7 validations y 4 acciones con feature control por instancia, expuesto como servicio OData V4.

La lógica de negocio vive en clases ABAP independientes de la implementación del comportamiento, con 32 tests de ABAP Unit. Sobrevivieron sin una línea de cambio a dos refactorizaciones del modelo de datos — el historial de commits lo enseña.

Las reglas que lo separan de un tutorial salen de haber estado delante de la báscula. Plausibilidad del peso medio por pieza: 500 pollos y 6.500 kg no son una desviación, son un error de conteo o de báscula. Vida útil restante mínima: el producto que no está caducado pero ya no sirve. Y una aceptación de desviación que registra quién y por qué en lugar de sobrescribir el peso recibido, porque de ahí salen las reclamaciones al proveedor.

Plausibilidad del peso medio por pieza	32 tests de ABAP Unit

El README del repositorio incluye un apartado explícito de qué no está implementado, y un documento de decisiones técnicas con las alternativas descartadas y el motivo de cada una.

Modelo CAP que encadena lote de proveedor → lote interno → producto terminado, con consumo automático por fecha de caducidad (FEFO): cuando el lote que antes caduca no basta, reparte la producción entre varios y deja el rastro completo de cuál salió de dónde.

Lo que separa esto de un ejercicio de CAP genérico: de los 4 productos del catálogo de ejemplo, solo el que caduca de verdad —aceite de oliva— recibió lotes con fecha de caducidad. Un palet o un escáner de códigos de barras no la necesitan, y el modelo no se la fuerza.

El README del repositorio documenta la decisión de desarrollo 100% local (cds watch + SQLite) sin disfrazarla de despliegue, con datos de ejemplo listos para reproducir el caso FEFO sin preparar nada a mano.

iFlow en SAP Integration Suite que conecta la recepción de mercancía de zgr-goods-receipt con una aplicación externa de alertas de vida útil: filtra entidades en borrador de un payload real capturado de la API, aplana la jerarquía Receipt → Item → Batch y entrega por HTTPS, con una Exception Subprocess que captura cualquier fallo de entrega en vez de dejarlo sin resolver.

Lo que separa esto de un tutorial de Integration Suite: la Exception Subprocess no se dio por buena en el diseño. Se probó deteniendo la aplicación externa a mitad de una ejecución real — la llamada HTTP falló, la ejecución saltó a la rama de captura de errores, y el mensaje completo terminó marcado como Completed, no como Failed.

El fallo real, absorbido paso a paso	El resultado: Completed, no Failed

El README del repositorio documenta por qué el origen es un payload de muestra y no un sondeo en vivo —restricciones de acceso de un tenant compartido, no una limitación oculta— y cómo se expone la aplicación externa con un túnel real.

La capa sobre la que se apoya el modelo de programación de CAP.

Proyecto	Qué es	Stack
canister-api	API REST con arquitectura MVC, filtrado y paginación
mundoacuatico	SPA que consume esa API: estado global, rutas protegidas, carga diferida
PokeApi	Sitio en producción en alcaan16.es

SAP

Web

Entornos

Formación oficial: 270 h en Experis Academy — ABAP Cloud 205 h + SAP BTP 65 h.