El código que empieza donde termina el estándar.

Informes, pantallas y formularios

Los informes que alguien abre cada mañana, las pantallas de entrada de datos, las salidas impresas, los procesos de fondo que corren de noche. Damos forma al desarrollo según cómo trabaja realmente la persona, diseñando la pantalla como parte de un flujo de trabajo y no como una necesidad técnica.

Si encaja mejor un enfoque orientado a objetos o uno clásico es una decisión que tomamos mirando la base de código existente y lo que el equipo del cliente podrá mantener.

Ampliar el estándar

Al intervenir en un flujo estándar, elegir el punto correcto suele importar más que el código. Una intervención hecha en el punto equivocado se rompe en la primera actualización; la que se hace en el correcto pasa años sin que nadie la note.

Cualquier regla que pueda cambiar va a una tabla mantenible en lugar de al código. Las reglas que difieren por sociedad, país o grupo de productos se gestionan así sin desarrollador.

Integración entre sistemas SAP

Mover datos entre distintos sistemas SAP del mismo grupo, entre sociedades separadas o entre el sistema antiguo y el nuevo durante una transición. La sincronización de datos maestros, el traspaso de documentos y los informes de conciliación son la parte habitual de ese trabajo.

Todo flujo que construimos es trazable: qué registro salió y cuándo, cuál falló y cómo se reprocesa el fallo se diseñan desde el principio. Un registro que desaparece en silencio es el defecto más caro que puede tener una interfaz.

Integración con aplicaciones no SAP

Aquí está el centro de gravedad. Hacemos que SAP hable con sistemas de ejecución de fabricación, software de laboratorio, aplicaciones de almacén y logística, proveedores de factura electrónica, interfaces bancarias, plataformas de comercio electrónico, herramientas de informes y con lo que la empresa haya construido para sí misma.

Antes de construir la conexión escribimos el contrato: qué evento produce qué registro, cómo se corresponden los campos, qué ocurre cuando la otra parte no responde y cuándo es seguro reenviar. Una interfaz construida antes de tener esas respuestas paraliza el negocio en el primer corte.

En el plano técnico, si la vía correcta es una conexión por servicios, un intercambio de ficheros y carpetas, un enlace a base de datos o una cola de mensajes lo decide lo que el otro sistema realmente puede hacer. La autenticación, el cifrado y el registro forman siempre parte del alcance.

Carga de datos y proceso masivo

Meter datos en el sistema es un problema de ingeniería propio. Tanto en migraciones puntuales como en cargas nocturnas buscamos las mismas tres cosas: validación, tratamiento del éxito parcial y capacidad de volver a ejecutar desde el principio.

En lugar de cargar los datos en bruto tal como llegan, los pasamos primero por validaciones. Dejar fuera un registro erróneo siempre sale más barato que limpiarlo después.

Optimización y entrega

En sistemas que llevan años funcionando esta es la petición más habitual: procesos que ya no caben en la ventana nocturna, pantallas que tardan minutos en abrirse, informes que se ralentizan a medida que crecen los datos. Medimos antes de tocar el código: optimizar sin medir es adivinar.

Tanto si escribimos el código como si lo heredamos, lo dejamos en condiciones de que otro equipo lo mantenga. La revisión de código, los estándares de nomenclatura y la documentación no son para nosotros un servicio adicional: son el trabajo.