Mantenimiento de precios de compra en SAP

Contexto

UAA implementó SAP S/4HANA en Supermercados y Corralones. Como parte del rediseño del proceso de compra a pago, el mantenimiento de precios de compra pasó a ser uno de los puntos de mayor fricción.

El problema y su costo

En el ERP anterior, cambiar el costo de un producto cambiaba su precio de venta. En SAP, el precio de venta sale del precio de compra del proveedor regular, por markup y por IVA. Cada cambio de lista hay que cargarlo en el registro info de compras de cada centro: una lista de 50 artículos se convierte en unas 500 líneas de carga.

Si el precio de compra queda desactualizado, el margen se calcula mal y se vende por debajo de lo pactado. El trabajo recae en el área administrativa, que además mantiene datos maestros, carga facturas y crea órdenes de compra.

Mi rol

El dolor lo plantearon las áreas de compras de Supermercado y Corralón. Definí el proceso, la arquitectura y las reglas de control; el código lo escribió Claude Code y yo validé cada versión con los usuarios.

La solución

Una herramienta que toma tres entradas (facturas del día, la lista del proveedor o el cálculo de costo), las cruza contra el export de registros info de SAP y genera el archivo de carga masiva. Un script replica cada condición en todos los centros, en paralelo, con reglas que deciden qué actualizar, qué crear y qué no tocar. Antes de generar el archivo, una persona revisa los cambios con la variación porcentual visible.

Decisiones

• Dentro del estándar de SAP. Un desarrollo ABAP o una integración por API abrían una brecha que el proyecto no aprobó. La solución usa los mecanismos nativos: export y carga masiva.
• Match exacto en lugar de fuzzy. La primera versión buscaba coincidencias aproximadas y tenía baja confiabilidad. El cruce exacto por código elimina el riesgo de actualizar el material equivocado.
• Nunca pisar una condición más nueva. Si otro usuario ya cambió el precio en un centro, la herramienta no lo sobrescribe y lo informa.
• Las escalas van a carga manual. Las condiciones con escalas se separan para una persona: la herramienta resuelve el volumen y deja el caso borde a quien conoce la excepción.
• Cada decisión queda registrada. Un reporte por centro y por registro explica qué se hizo y por qué.

Resultados

Una lista típica pasó de unos 45 a unos 15 minutos, y la herramienta se usa todos los días. En la corrida más grande, 2.225 condiciones se convirtieron en 20.711 líneas de carga para todos los centros, con 37 conflictos que la regla protegió.

Cómo lo escalaría

En un cliente enterprise: lectura y escritura de condiciones por OData o BAPI de S/4HANA, reglas como servicio, aprobaciones según el porcentaje de variación y el histórico de condiciones en una capa de datos para detectar variaciones anómalas por proveedor. Con process mining sobre el P2P se mide el antes y el después: facturas bloqueadas por diferencia de precio y frecuencia de cambios manuales.