233 artículos técnicos gratuitos sobre SAP para consultores. FI-CO, MDG, MM-SD, Proveedores, Acreedores y Debug ABAP. Cada día se muestra uno diferente en el brief diario.
Las cuentas de reconciliación conectan el libro mayor con las subcuentas de deudores y acreedores. No admiten contabilizaciones manuales directas; se actualizan automáticamente al registrar en las cuentas auxiliares.
Los tipos de documento (SA, KR, DR, DZ) controlan el rango de numeración, las clases de cuenta permitidas y la gestión de IVA. Son la primera línea de configuración en cualquier implantación FI.
Los centros de coste recogen costes recurrentes de áreas funcionales. Las órdenes internas agrupan costes de proyectos temporales con inicio y fin definidos, dando mayor granularidad al control de costes.
Las claves (01, 31, 40, 50) determinan el sentido debe/haber, el tipo de cuenta permitido y los campos obligatorios en cada línea de documento FI. Configurarlas bien evita errores sistemáticos.
El cierre FI incluye depreciación (AFAB), valoración de moneda extranjera (FAGL_FC_VAL), traslado de periodificaciones y liquidación de órdenes. El orden de ejecución es crítico para evitar inconsistencias.
Las condiciones de pago definen los plazos de vencimiento y los descuentos por pronto pago. SAP calcula automáticamente la fecha de vencimiento y el importe del descuento al contabilizar cada factura.
El document splitting en New GL divide automáticamente cada línea de documento entre las dimensiones de reporting (profit center, segmento) para obtener balances completos por cada dimensión configurada.
La baja de un activo en SAP requiere contabilizar la venta o desguace en ABAON (sin ingresos) o F-92 (con ingresos). El sistema calcula automáticamente la depreciación acumulada y la pérdida o ganancia.
El IVA en SAP se gestiona mediante claves fiscales asignadas a cada línea de documento. El procedimiento fiscal determina las cuentas contables, los porcentajes y el tratamiento por país y tipo de operación.
La depreciación en SAP se calcula según la clave asignada a cada activo. AFAB ejecuta la depreciación periódica y genera los documentos FI, pudiendo ejecutarse en modo test antes de la ejecución definitiva.
Los profit centers permiten generar balance y cuenta de resultados por unidad de negocio dentro de una sociedad. En S/4HANA están completamente integrados en ACDOCA sin tablas separadas adicionales.
El Availability Control bloquea o advierte cuando un gasto supera el presupuesto asignado a un centro de coste u orden interna, antes de que se contabilice, garantizando el control presupuestario preventivo.
Las varianzas en CO-PC muestran la diferencia entre el coste estándar planificado y el coste real de producción, permitiendo identificar ineficiencias en materiales, mano de obra y gastos generales.
Las Financial Statement Versions definen la estructura del balance y la cuenta de resultados. Agrupan cuentas del plan de cuentas en posiciones de la estructura financiera para el reporting legal y de gestión.
El módulo de retenciones gestiona la retención fiscal sobre pagos a terceros. SAP calcula automáticamente el importe a retener y genera los asientos contables al contabilizar el pago o la factura según configuración.
El Ledger Approach permite mantener múltiples libros contables paralelos con diferentes principios (HGB, IFRS, US-GAAP) sin duplicar la entrada de datos, gracias al Universal Journal de S/4HANA.
Los activos en curso (AuC) en SAP capitalizan los costes de proyectos de inversión antes de que el activo esté operativo. Al finalizar el proyecto se realiza la liquidación al activo definitivo mediante AIAB.
Las sustituciones rellenan automáticamente campos del documento FI según reglas configurables. Las validaciones verifican que los datos introducidos cumplen las reglas de negocio antes de contabilizar.
IFRS 16 obliga a capitalizar los contratos de arrendamiento en el balance. SAP gestiona esto mediante el módulo de Lease Accounting (RE-FX o Contract Accounting), creando automáticamente el activo por derecho de uso.
IFRS 15 regula cuándo y cómo reconocer los ingresos. SAP Revenue Accounting and Reporting (RAR) automatiza el cumplimiento de IFRS 15 identificando obligaciones de desempeño y calculando el precio de asignación.
El Financial Closing Cockpit (FCC) en SAP orquesta y monitoriza todas las tareas del cierre contable, asignando responsables, fechas límite y dependencias entre tareas para garantizar un cierre ordenado.
La planificación de costes en CO permite definir valores objetivo por centro de coste y elemento de coste para cada período. Estos valores sirven de referencia para el análisis de varianzas durante el año.
Los ciclos de distribución (KSUB) reparten costes de centros auxiliares a centros receptores según bases de distribución (horas, m², empleados). El reparto (KSIB) hace lo mismo pero desglosando los elementos de coste.
Cuando se contabiliza una entrada de mercancía en MM, SAP determina automáticamente las cuentas FI mediante la configuración de la determinación de cuentas (OBYC). Entender este proceso es clave para análisis FI.
El coste de producto en SAP calcula el coste estándar de un material fabricado sumando materia prima (lista de materiales), mano de obra (hoja de ruta) y gastos generales (tasas de imputación de centros de coste).
Las tasas de actividad (precio planificado por unidad de actividad) permiten valorar el consumo de servicios internos entre centros de coste. Por ejemplo, el coste por hora de la maquinaria del centro de producción.
SAP puede generar informes de flujo de caja directamente desde los datos de FI clasificando los movimientos en actividades operativas, de inversión y financiación según la estructura configurada en la FSV.
Las operaciones entre sociedades del mismo grupo generan partidas que deben eliminarse en la consolidación. SAP gestiona esto mediante los campos Trading Partner y Segmento en el maestro de cuentas.
Los informes estándar de FI cubren desde el balance hasta el análisis de partidas individuales. Conocer los códigos de transacción correctos para cada necesidad ahorra tiempo y evita desarrollos innecesarios.
S/4HANA convive con transacciones SAP GUI clásicas y apps Fiori modernas. Las apps Fiori ofrecen mejor UX y son el futuro de SAP, pero las transacciones clásicas siguen siendo necesarias para configuración.
En EE.UU. y Canadá el impuesto sobre ventas varía por estado, condado y ciudad. SAP gestiona esta complejidad mediante Tax Jurisdiction Codes que identifican la ubicación fiscal exacta de cada operación.
Los anticipos en SAP requieren una cuenta especial de reconciliación para separarse de las facturas ordinarias. El proceso completo: solicitud (F-47), contabilización del anticipo (F-48) y compensación con factura (F-54).
En países con alta inflación SAP permite revalorizar activos fijos ajustando su valor en libros y la depreciación acumulada. Esto mantiene los valores del balance más cerca del valor real en entornos inflacionarios.
Cuando el pago de un cliente o a un proveedor difiere ligeramente del importe de la factura, SAP puede compensar automáticamente si la diferencia está dentro de los límites de tolerancia configurados.
Los elementos de coste primarios (categoría 1) corresponden a cuentas de gasto de FI. Los secundarios (categorías 21-43) solo existen en CO y se usan para distribuciones, repartos y cálculos de tasas internas.
SAP permite llevar la contabilidad en hasta tres monedas paralelas por sociedad: la moneda del grupo, la moneda dura y la moneda de la transacción. Esto facilita el reporting multinacional sin conversiones manuales.
La categoría del elemento de coste determina su uso en CO: 1=costes primarios, 11=ingresos, 21=liquidación de órdenes, 22=transferencias, 41=overheads, 43=procesos de negocio (ABC). Elegir bien la categoría es crítico.
El cierre de ejercicio en FI-AA incluye la depreciación del último período, el informe de cierre de año fiscal (AJAB) y la apertura del nuevo ejercicio (AJRW). El orden de ejecución es estrictamente obligatorio.
SAP Cash Management integra los saldos bancarios reales con las previsiones de cobros y pagos para proporcionar una visión completa de la posición de liquidez de la empresa en cada moneda y banco.
SAP puede calcular y contabilizar automáticamente intereses sobre saldos vencidos de clientes. La configuración en OBAC y la ejecución de F.44 permiten automatizar este proceso de ingresos financieros adicionales.
La Cuenta de Resultados Analítica (CO-PA) permite analizar la rentabilidad por cliente, producto o canal de distribución. En S/4HANA, CO-PA basada en cuenta es la modalidad recomendada por estar integrada en ACDOCA.
El Business Partner reemplaza en S/4HANA los maestros separados de cliente y proveedor. La función de BP determina los campos disponibles y los roles necesarios para cada proceso de negocio empresarial.
Los Change Requests canalizan solicitudes de creación o modificación de datos maestros a través de flujos de aprobación configurables. Cada CR tiene un tipo, etapas definidas y agentes responsables de validar.
MDG usa Business Rule Framework plus para definir validaciones sobre atributos del maestro de datos. Estas reglas verifican los datos antes de activar un registro y pueden ser tan simples o complejas como se requiera.
El DRF permite distribuir datos maestros validados de MDG a sistemas satélite del landscape. Garantiza que todos los sistemas trabajen con la misma versión aprobada de cada maestro sin intervención manual.
MDG-C gestiona el ciclo de vida del maestro de clientes garantizando datos coherentes entre SD, FI-AR y CRM. Los CRs controlan qué atributos puede modificar cada rol de la organización para el cliente.
MDG-M centraliza la creación y mantenimiento del maestro de materiales, garantizando que cada nuevo material tenga los datos completos y validados antes de estar disponible para compras o producción.
El Key Mapping gestiona la correspondencia entre los códigos de un maestro en distintos sistemas. Permite que el mismo proveedor tenga códigos diferentes en SAP, CRM y el sistema legacy, manteniendo la trazabilidad.
MDG registra un historial completo de todos los cambios en datos maestros: quién cambió, qué campo, desde qué valor, a qué valor y cuándo. Esto facilita auditorías internas y el cumplimiento normativo.
MDG tiene un modelo de autorización granular que controla qué usuarios pueden crear CRs, qué entidades pueden modificar y qué campos son accesibles para cada rol, garantizando el principio de mínimo privilegio.
MDG ofrece herramientas para crear o modificar grandes volúmenes de datos maestros. Incluye carga mediante ficheros planos, APIs REST, BAPIs o replicación desde sistemas fuente externos al sistema MDG.
MDG puede gobernar el plan de cuentas, garantizando que cualquier nueva cuenta del mayor o modificación pase por un proceso de aprobación controlado antes de estar disponible para contabilización.
MDG puede extender el gobierno de datos a los objetos de CO, como centros de coste, garantizando que las altas y modificaciones de estructuras organizativas de CO pasen por el proceso de aprobación corporativo.
El gobierno de profit centers con MDG asegura que los cambios en la estructura de profit centers (nuevos segmentos, reorganizaciones) se gestionen de forma controlada y coordinada entre FI y CO.
MDG puede gestionar el ciclo de vida del maestro de activos fijos, garantizando que las altas, transferencias y bajas de activos pasen por procesos de aprobación controlados con trazabilidad completa.
El concepto de stewardship en MDG define quién es responsable de la calidad de cada tipo de dato maestro. Los data stewards son los responsables de validar y aprobar los Change Requests en su área de competencia.
MDG en S/4HANA se puede integrar con sistemas externos (CRM, portales de proveedores, e-commerce) mediante SAP Integration Suite, publicando y consumiendo datos maestros a través de APIs REST y OData.
MDG incluye capacidades analíticas para medir la calidad de los datos maestros, el tiempo medio de aprobación de CRs y el porcentaje de registros que cumplen las reglas de calidad definidas en el sistema.
La deduplicación en MDG identifica registros maestros duplicados y proporciona herramientas para fusionarlos en un único registro consolidado sin perder el histórico de transacciones asociadas a cada código.
El customizing de MDG (tipos de CR, reglas de validación, workflows) se transporta entre mandantes mediante el sistema estándar de transportes. Planificar bien la estrategia de transporte es crítico para el proyecto.
MDG Foundation puede desplegarse sobre ERP o BW como sistema standalone. MDG en S/4HANA está completamente integrado y comparte la base de datos productiva, eliminando latencias de replicación y simplificando la arquitectura.
MDG gestiona jerarquías de datos maestros como la de profit centers, centros de coste o materiales. Centraliza los cambios estructurales garantizando coherencia en todos los sistemas del landscape empresarial.
MDG puede gobernar el maestro de bancos, garantizando que los datos bancarios (IBAN, BIC, nombre del banco) de proveedores y clientes sean correctos y aprobados antes de usarse en los procesos de pago.
MDG puede gestionar datos de referencia como países, regiones, divisas o unidades de medida, garantizando que estos datos maestros básicos sean consistentes en todos los sistemas del grupo empresarial.
Las versiones recientes de MDG incorporan capacidades de inteligencia artificial para clasificación automática de proveedores, detección de datos incorrectos y sugerencias de completitud de maestros antes de activar.
MDG expone sus funciones mediante APIs OData v4, permitiendo que sistemas externos inicien procesos de gobierno de datos de forma programática y reciban notificaciones cuando los datos maestros son aprobados.
La activación es el proceso por el que los datos validados y aprobados en el CR se escriben en las tablas productivas, haciéndolos disponibles para los procesos de negocio en el sistema SAP.
La migración de datos maestros a S/4HANA es una oportunidad para implementar MDG como nuevo sistema de gobierno, limpiar los datos heredados y establecer procesos de calidad de dato desde el inicio del nuevo sistema.
El Reglamento General de Protección de Datos (GDPR) requiere que las empresas conozcan qué datos personales tienen y puedan gestionarlos (acceso, rectificación, supresión). MDG facilita el cumplimiento del GDPR.
SAP ofrece MDG como servicio en la nube (parte de SAP S/4HANA Cloud o como solución standalone), permitiendo el gobierno de datos maestros sin la necesidad de gestionar infraestructura on-premise propia.
MDG se integra con los procesos de negocio para garantizar que solo se usen datos maestros validados. Un proveedor no puede usarse en pedidos de compra hasta que su CR esté aprobado y el BP esté activado.
En S/4HANA Cloud, el gobierno de datos maestros se gestiona a través de las apps predefinidas de SAP. La configuración es más restrictiva pero garantiza actualizaciones automáticas sin impacto en el gobierno.
MDG puede gestionar el gobierno de plantas (WERKS) y centros logísticos, garantizando que la creación de nuevas ubicaciones productivas siga un proceso controlado con los datos mínimos requeridos para operar.
Sin MDG, los datos maestros se crean directamente en las transacciones operativas (XK01, MM01) sin control de calidad. MDG añade una capa de gobierno, validación y aprobación que mejora significativamente la calidad.
Para grupos empresariales con múltiples instancias SAP, la estrategia de MDG Hub centraliza el gobierno en un único sistema desde el que se distribuyen los datos maestros validados a todas las instancias receptoras.
Las apps Fiori de MDG ofrecen una interfaz intuitiva para la gestión de datos maestros, con wizards guiados para la creación de CRs, dashboards de estado y flujos de aprobación en dispositivos móviles.
MDG permite definir reglas de completitud que verifican que todos los atributos obligatorios de un maestro están presentes antes de activarlo. Un registro incompleto no puede aprobarse ni replicarse.
Cuando un CR no puede activarse por errores en los datos (duplicados, violaciones de unicidad, valores inválidos), MDG genera un registro de error que el steward debe resolver antes de reintentar la activación.
El maestro de materiales es el eje central de MM. Cada vista controla un proceso distinto: MRP para planificación, Compras para aprovisionamiento, Contabilidad para valoración.
Los tipos de material determinan el comportamiento del maestro: si se valora en stock, qué vistas están disponibles y qué movimientos son posibles. ROH es materia prima, HALB semielaborado, FERT producto terminado.
El MRP calcula automáticamente qué materiales hacen falta, cuándo y en qué cantidad. Analiza stock disponible, demandas activas y genera propuestas de aprovisionamiento o fabricación.
La entrada de mercancía (GR) registra la recepción de materiales del proveedor. El movimiento 101 genera el asiento de stock y actualiza el GR/IR, conectando MM y FI automáticamente.
SAP distingue varios tipos de stock: libre disponible, bloqueado, en control de calidad, en tránsito y en consignación. Conocer la diferencia es crítico para la precisión del inventario.
El inventario físico en SAP: crea el documento (MI01), introduce el recuento (MI04) y contabiliza diferencias (MI07) generando el asiento de ajuste contable automáticamente.
En SAP hay dos métodos: precio estándar (S) que fija un precio anual y registra varianzas, y precio medio variable (V) que actualiza el coste con cada entrada de mercancía.
La BOM define los componentes necesarios para fabricar un producto. Es la base del MRP, la planificación de producción y el cálculo de costes. Una BOM incorrecta genera errores en cascada.
Las hojas de ruta definen las operaciones de fabricación, su secuencia, los centros de trabajo donde se ejecutan y los tiempos necesarios para la programación de órdenes.
La gestión por lotes permite rastrear cada partida desde su entrada hasta el cliente. Es obligatoria en farmacia, alimentación y química para cumplir regulaciones de trazabilidad.
SAP WM gestiona ubicaciones, Transfer Orders y movimientos físicos del almacén. En S/4HANA se migra a EWM con mayor funcionalidad para almacenes complejos y automatizados.
El Material Ledger calcula el coste real de los materiales al cierre del período, absorbiendo varianzas de producción y diferencias de precio de compra para el reporting preciso.
El maestro de clientes tiene datos generales, de sociedad FI y de área de ventas SD. El área de ventas determina qué condiciones y datos aplican a cada proceso de venta.
El sistema de precios en SD es uno de los más potentes de SAP. Precios, descuentos, recargos e impuestos se configuran como condiciones que se combinan en un esquema de cálculo.
El pedido de venta es el documento central de SD. Define qué vendes, a quién, cuándo y a qué precio. El tipo (OR=estándar, CS=cash sale, RO=rush order) determina el flujo completo.
El Available-to-Promise verifica si hay stock para confirmar la fecha de entrega. SAP considera stock disponible, entradas planificadas y otras demandas para calcular la cantidad confirmable.
La entrega gestiona el proceso físico de sacar material del almacén al cliente. Incluye picking, embalaje y expedición con el albarán como documento físico de la entrega.
La factura SD genera el cargo al cliente y el ingreso en FI. El tipo (F2=factura normal, RE=nota de abono, G2=nota de cargo) determina las cuentas contables actualizadas.
SAP gestiona límites de crédito de clientes en FD32. Si un pedido supera el límite se bloquea automáticamente para aprobación. El nuevo FSCM Credit Management ofrece análisis más sofisticados.
Las devoluciones en SD siguen un proceso: pedido de devolución (RE), entrega de devolución con retorno al stock y nota de abono para compensar al cliente.
La determinación de cuentas de ingresos VKOA define qué cuenta FI se actualiza al facturar en SD, basándose en el tipo de material, grupo del cliente y esquema de imputación.
Las ventas intercompany ocurren cuando la empresa vendedora y la que entrega son distintas. SAP genera la factura intercompany automáticamente con asientos en ambas sociedades.
La consignación envía materiales al cliente sin transferir la propiedad hasta el consumo. SAP gestiona el stock especial W en poder del cliente visible en MB52 con indicador especial.
SAP gestiona la expedición mediante determinación automática de punto de expedición, ruta y transportista según el destino, incoterm y tipo de transporte configurados.
La determinación de impuestos en SD usa el procedimiento TAXE que combina país del emisor, receptor y la clasificación fiscal del material y cliente para calcular el IVA.
Las reclamaciones se gestionan con notificaciones QM vinculadas al pedido o entrega. Permiten registrar el problema, asignar responsables y controlar los costes de la reclamación.
Los contratos marco negocian precios y condiciones para un volumen o período determinado. Los pedidos posteriores referencian el contrato y aplican las condiciones negociadas.
La determinación de materiales sustituye automáticamente un material por otro en el pedido según reglas configuradas. Útil para descatalogaciones, promociones y mejoras de producto.
SAP SD acumula datos en tablas estadísticas actualizadas en tiempo real. Estos datos alimentan informes estándar y dashboards de SAP Analytics Cloud sin necesidad de extractor.
En S/4HANA la gestión de outputs (confirmaciones, albaranes, facturas) migra al Output Management Framework, soportando PDF, XML, EDI y formatos legales de cada país.
Cuando un FERT no tiene stock SD puede disparar automáticamente una orden de producción en PP. La integración usa el tipo de aprovisionamiento del maestro y el ATP check.
El módulo CS extiende SD para gestionar reparaciones, mantenimiento de equipos del cliente y contratos de servicio, integrándose con PM para los recursos técnicos.
Al cierre en SD verifica entregas no facturadas, facturas bloqueadas, pedidos pendientes y estadísticas del período. Es el checklist del responsable de SD en cada cierre mensual.
SAP Commerce Cloud se integra con el backend SD para procesar pedidos de canales digitales mediante APIs OData del Gateway SAP que conectan el eCommerce con el ERP.
El maestro de proveedor tiene nivel mandante (datos generales), sociedad (FI) y organización de compras (MM). Cada nivel controla aspectos distintos del proceso de aprovisionamiento y pago al proveedor.
La verificación de facturas valida que la factura del proveedor coincida con el pedido y la entrada de mercancía. Genera automáticamente el documento FI de deuda al acreedor al contabilizar el documento.
F110 selecciona partidas abiertas de acreedores, calcula descuentos por pronto pago y genera órdenes de pago según los métodos configurados. Es el proceso central de cuentas a pagar en cualquier empresa SAP.
La cuenta GR/IR recoge la diferencia temporal entre la entrada de mercancía y la recepción de la factura. Es una cuenta de tránsito que debe saldarse cuando ambos documentos están contabilizados en SAP.
SAP MM evalúa proveedores automáticamente en base a calidad, plazos de entrega, precio y servicio. Las puntuaciones influyen en la selección automática de fuente de aprovisionamiento en el proceso de MRP.
La estrategia de release define flujos de aprobación para pedidos de compra según importe, categoría de material o centro. Garantiza el control del gasto antes de comprometerse con el proveedor.
Los contratos marco en SAP MM gestionan acuerdos de aprovisionamiento a largo plazo con proveedores. Permiten negociar precios y condiciones para volúmenes comprometidos durante períodos definidos.
Una devolución a proveedor requiere el movimiento 122 en MIGO (revertir la GR), la creación de nota de crédito en MIRO y posiblemente un pedido de devolución. El proceso exacto varía según la configuración.
El parking de facturas permite guardar un documento incompleto sin que genere asientos contables. El documento aparcado solo afecta al libro mayor cuando se contabiliza definitivamente por el usuario autorizado.
El esquema de determinación de precios en MM define cómo SAP calcula el precio de compra final a partir de precios base, descuentos, recargos, aranceles y otros conceptos aplicables a cada condición.
En subcontratación la empresa envía componentes al proveedor para su transformación. SAP gestiona esto con el tipo de aprovisionamiento 'S' en el maestro de materiales y el movimiento especial 543.
El intercambio electrónico de documentos permite automatizar el envío de pedidos y la recepción de facturas electrónicas. SAP usa IDocs como ORDERS (pedido) e INVOIC (factura) para este intercambio automático.
El MRP genera automáticamente solicitudes de pedido cuando el stock cae bajo el punto de pedido o cuando hay necesidades de producción planificadas. El comprador convierte estas solicitudes en pedidos reales.
Los servicios externos se gestionan con pedidos de servicio (tipo D en ME21N) y hojas de entrada de servicios (ML81N). La hoja de entrada equivale a la GR en compra de materiales y activa la verificación de factura.
Los registros info (ME11) almacenan las condiciones de precio específicas de la relación material-proveedor. Son la fuente de datos que SAP consulta al crear un pedido para determinar el precio automáticamente.
La lista de fuentes (ME01) define qué proveedores están autorizados a suministrar un material específico a un centro. Puede bloquear el aprovisionamiento de proveedores no autorizados para materiales críticos.
La cuota de reparto (MEQ1) define el porcentaje de las necesidades de un material que se distribuye entre varios proveedores. El MRP respeta estas cuotas al generar solicitudes de pedido automáticamente.
El plan de facturación en SAP permite programar facturas periódicas para contratos de mantenimiento, alquileres o servicios recurrentes, generando automáticamente las solicitudes de pago en las fechas acordadas.
El cargo posterior (subsequent debit) y el abono posterior (subsequent credit) en MIRO permiten ajustar el valor de una factura ya contabilizada sin necesidad de anularla y recontabilizarla completamente.
Las tolerancias en OMR6 definen los límites aceptables de diferencia entre pedido y factura en precio y cantidad. Superarlos bloquea automáticamente la factura para pago hasta que se revise y libere.
Los pedidos blanket (límite de valor) permiten realizar múltiples compras de bajo importe a un proveedor sin crear un pedido por cada transacción, usando un único pedido con límite de valor global.
En el modelo de consignación el proveedor mantiene stock en las instalaciones de la empresa pero sin transferir la propiedad. La deuda con el proveedor solo se genera al consumir el stock de consignación.
Los House Banks representan las cuentas bancarias de la empresa desde las que se ejecutan los pagos. Su correcta configuración en SAP es imprescindible para que F110 genere los ficheros de pago correctamente.
Los Incoterms definen las responsabilidades de transporte y seguro entre comprador y vendedor. En SAP se configuran en el maestro de proveedor y en los pedidos, afectando al cálculo de costes de aprovisionamiento.
Las compras de importación en SAP requieren gestionar aranceles aduaneros, gastos de despacho e IVA de importación. Estos costes deben incluirse en el coste de adquisición del material valorado en el almacén.
El aprovisionamiento de terceros (third-party) en SAP permite que un pedido de cliente genere automáticamente un pedido de compra al proveedor, quien entrega directamente al cliente final sin pasar por el almacén.
SAP permite centralizar las compras mediante organizaciones de compras globales que negocian contratos marco para todas las sociedades del grupo, aprovechando el volumen para obtener mejores condiciones.
El Payment Medium Workbench (PMW) en SAP permite configurar y generar ficheros de pago en cualquier formato bancario sin necesidad de programación ABAP, usando configuración declarativa y plantillas XML.
El número de referencia del proveedor (campo XBLNR en BKPF) almacena el número de factura asignado por el proveedor. SAP usa este campo para detectar facturas duplicadas y para la conciliación con extractos del proveedor.
Los grupos de cuentas de proveedor controlan los campos del maestro (obligatorios, opcionales, suprimidos), el rango de numeración y si el número lo asigna SAP automáticamente o lo introduce el usuario.
SAP Ariba extiende las capacidades de compras SAP al mundo digital: catálogos electrónicos, subastas inversas, onboarding de proveedores y gestión de contratos. Se integra con SAP MM mediante estándar cXML.
En contratos de construcción o servicios es común retener un porcentaje del pago como garantía de cumplimiento. SAP permite configurar estas retenciones en el plan de facturación del pedido de servicios.
Cuando se contabiliza una GR en SAP, el sistema determina automáticamente las cuentas FI mediante la configuración de OBYC. Esta tabla vincula la transacción MM con la cuenta contable correspondiente.
SAP SRM (Supplier Relationship Management) ha evolucionado en S/4HANA hacia SAP Ariba para la gestión de proveedores y SAP Central Procurement para la centralización de compras en entornos multi-sistema.
La factura electrónica obligatoria en España (Verifactu y FACeB2B) requiere que SAP genere y transmita facturas en formato XML firmado digitalmente. SAP ofrece integración via SAP Document and Reporting Compliance.
Los contratos de servicios externos en SAP permiten gestionar acuerdos de mantenimiento, limpieza o seguridad con proveedores de servicios recurrentes, controlando presupuesto y consumo a lo largo del tiempo.
El proceso de homologación de proveedores en SAP controla que solo proveedores aprobados puedan ser usados en pedidos de compra. La lista de fuentes y los indicadores de bloqueo son los mecanismos clave.
Los informes de análisis de compras en SAP MM permiten identificar pedidos sin factura, facturas sin pedido, diferencias de precio y desviaciones respecto a contratos marco negociados con los proveedores.
SAP permite registrar y monitorizar indicadores de riesgo de proveedor como la concentración de gasto, los históricos de incumplimiento y las dependencias críticas que pueden afectar a la cadena de suministro.
SAP Ariba permite realizar subastas inversas (reverse auctions) donde múltiples proveedores compiten por un contrato, reduciendo el precio final. Los resultados se pueden importar directamente a contratos de SAP MM.
La integración de criterios ESG (Environmental, Social, Governance) en el proceso de compras SAP permite evaluar proveedores no solo por precio sino también por su impacto ambiental y social.
Los catálogos de compras electrónicos en SAP permiten que los usuarios compren directamente desde catálogos de proveedores, con los precios y productos predefinidos, generando solicitudes de pedido automáticas.
Al recibir una entrega del proveedor, SAP puede controlar el proceso de inspección de calidad antes de aceptar la mercancía en el almacén. El lote de inspección QM se crea automáticamente con el movimiento de GR.
El aging de acreedores muestra facturas pendientes por rangos de vencimiento. Es la herramienta esencial para gestionar el flujo de caja, priorizar pagos y mantener relaciones sanas con proveedores estratégicos.
FBL1N muestra todas las partidas de un acreedor: abiertas, compensadas y aparcadas. Es la herramienta de trabajo diaria del equipo de cuentas a pagar para consultar el estado de facturas y pagos.
La compensación elimina del libro auxiliar las partidas que se cancelan entre sí (factura contra abono, pago contra factura) sin movimiento de efectivo adicional, manteniendo el libro de acreedores limpio.
Los anticipos requieren una cuenta alternativa de reconciliación configurada en OBYR para no mezclarlos con facturas ordinarias. Sin ella el aging y los informes de vencimientos quedan distorsionados.
Con facturas en moneda extranjera SAP valoriza las diferencias de tipo de cambio en cada cierre, generando asientos automáticos de ganancias o pérdidas por cambio que afectan al resultado del período.
Las notas de crédito del proveedor reducen la deuda pendiente. Se contabilizan con FB65 (standalone FI) o en MIRO referenciando la devolución de mercancía con movimiento 122 en MIGO para mantener trazabilidad.
Los pagos SEPA generan ficheros XML según el esquema pain.001 para transferencias. La configuración correcta del método de pago SEPA es crítica para el proceso bancario y la reconciliación automática.
SAP permite bloquear pagos a un proveedor a nivel de factura individual o a nivel de maestro. Los bloqueos evitan pagos no autorizados durante disputas comerciales, auditorías o procesos de verificación.
Cuando un pago se realiza dentro del plazo de descuento, SAP captura automáticamente el cash discount al ejecutar F110. La diferencia entre el importe de la factura y el pago se contabiliza en la cuenta de descuentos.
La conciliación bancaria en SAP compara el extracto del banco con las partidas abiertas de pagos del sistema. Identifica pagos no registrados, diferencias de importe y movimientos bancarios sin documento SAP.
El netting permite compensar deudas con un partner que es simultáneamente cliente y proveedor, reduciendo el importe real a pagar o cobrar. SAP gestiona esto mediante la compensación cruzada entre cuentas.
SAP Cash Management permite prever los pagos futuros a proveedores basándose en facturas pendientes y sus fechas de vencimiento, proporcionando una visión completa de la posición de liquidez futura.
SAP gestiona las obligaciones de información fiscal sobre pagos a proveedores. En España, el Modelo 347 (operaciones con terceros) se genera a partir de los datos contabilizados en FI durante el ejercicio fiscal.
El cierre de cuentas a pagar requiere verificar facturas sin contabilizar, compensar partidas abiertas, revisar el aging, ejecutar valoración de moneda extranjera y conciliar el libro auxiliar con el mayor.
F-53 permite registrar pagos manuales asignándolos a facturas abiertas específicas. F-58 genera además el soporte físico de pago (cheque o transferencia). Ambas son alternativas a F110 para pagos urgentes.
Los pagos duplicados a proveedores son un riesgo de control interno significativo. SAP tiene herramientas para detectarlos: la validación de duplicados en MIRO y los informes de análisis de pagos.
SAP puede calcular y contabilizar automáticamente los intereses de demora sobre facturas pagadas fuera de plazo. Este proceso es útil en contratos con cláusulas de penalización por retraso en los pagos.
SAP puede generar y enviar automáticamente extractos de cuenta a proveedores, mostrando el estado de sus facturas y pagos. Esto reduce las consultas de proveedores y mejora la transparencia en la relación.
Las partidas aparcadas en SAP son documentos incompletos que no generan movimiento contable. En cuentas a pagar se usan para registrar facturas pendientes de revisión, aprobación adicional o datos faltantes.
F110 tiene opciones avanzadas que muchos consultores no explotan: tolerancias de pago, grupos de pago, fechas de valor diferenciadas por banco y opciones de agrupación de partidas en un único transfer.
FK10N proporciona una visión de la posición total de un acreedor: saldo total, partidas abiertas por vencimiento y estadísticas de pagos históricos. Es la vista resumen del maestro de deuda con cada proveedor.
Los mandatos SEPA de adeudo directo autorizan a la empresa a cargar en la cuenta del deudor. En SAP se gestionan en el maestro del cliente y son obligatorios para los pagos SEPA B2B y Core.
Cuando un deudor no paga, SAP permite registrar provisiones por insolvencia (individual o global) que reducen el valor de los créditos en el balance. Esta es la interfaz entre FI y la gestión del riesgo de crédito.
Los grupos de cuentas de acreedor controlan los campos del maestro, el rango de numeración y si el número lo asigna SAP o el usuario. Un buen diseño de grupos facilita la segmentación y reporting de proveedores.
Los pagos entre sociedades (cross-company code payments) permiten que una sociedad SAP pague en nombre de otra. Esto genera asientos de compensación intercompany automáticamente en ambas sociedades.
Las entradas periódicas o recurrentes en SAP permiten programar asientos contables que se repiten con regularidad (mensualmente, trimestralmente) sin necesidad de contabilizarlos manualmente cada período.
Los asientos de referencia en SAP son documentos modelo que sirven de base para crear nuevos documentos con la misma estructura, acelerando la entrada de datos en operaciones repetitivas.
El Modelo 347 declara las operaciones con clientes y proveedores que superan 3.005,06€ al año. SAP acumula automáticamente los importes de todas las facturas del año para generar el fichero de la declaración.
Las retenciones de garantía sobre pagos a proveedores de construcción o servicios de proyecto se gestionan en SAP mediante partidas especiales que se liberan automáticamente en la fecha acordada.
En situaciones urgentes donde no se puede esperar al ciclo regular de F110, SAP permite ejecutar pagos manuales inmediatos con F-53 (ya ejecutados) o F-58 (genera el soporte de pago con el banco).
Al cierre de período, muchos gastos están devengados pero no facturados aún. SAP permite registrar provisiones manuales o automáticas para que el resultado del período refleje el gasto real generado.
El modo debug se activa con /H en la barra de comandos. Permite ejecutar el programa paso a paso, inspeccionar variables en tiempo real y modificar valores para probar escenarios sin cambiar el código fuente.
Los watchpoints detienen la ejecución automáticamente cuando una variable cambia de valor. Son la herramienta más eficiente para rastrear modificaciones inesperadas en campos clave como totales o indicadores.
SAT registra el tiempo de ejecución de cada instrucción y llamada a función, identificando exactamente qué parte del código consume más tiempo. Es el punto de partida de cualquier tarea de optimización.
ST22 contiene todo para resolver un error: tipo de excepción, línea exacta, call stack completo y valores de las variables en el momento del fallo. Es el punto de partida de cualquier análisis de error de programa.
Los field symbols son punteros ABAP que apuntan a cualquier variable en tiempo de ejecución. Saber leerlos en el debugger es fundamental cuando se trabaja con tablas genéricas o estructuras dinámicas.
SQL Trace registra todas las sentencias SQL ejecutadas por un programa, mostrando el tiempo de respuesta de la base de datos, el número de registros leídos y si se usó un índice en cada SELECT.
Los ABAP Debugger Scripts permiten escribir código ABAP que se ejecuta dentro del debugger, automatizando tareas repetitivas como registrar valores de variables en cada iteración de un loop o modificar datos.
El debugging remoto permite depurar programas que se ejecutan en producción desde el IDE de desarrollo. Se usa con extrema precaución para resolver errores irreproduzibles en otros entornos de sistema.
El Memory Inspector en el ABAP Debugger permite analizar el consumo de memoria de variables y objetos en tiempo real, identificando qué tablas internas o strings consumen más memoria en el proceso.
Depurar implementaciones de BAdI requiere activar el debugger en el momento en que se llama al enhancement spot. Sin conocer el flujo del estándar, encontrar el punto de entrada exacto puede ser complejo.
Depurar código ABAP orientado a objetos requiere familiaridad con el call stack de métodos y la navegación entre instancias de objetos. El debugger de S/4HANA tiene soporte nativo para visualizar objetos.
Los Checkpoint Groups permiten activar assertions y breakpoints de forma selectiva en producción sin modificar el código fuente. Son la alternativa segura al debugging directo en entornos productivos.
Los IDocs son el mecanismo estándar de intercambio de datos en SAP. Cuando un IDoc falla es necesario depurar el proceso de entrada o salida para identificar si el error está en validación, posting o conversión.
Los ABAP Unit Tests permiten probar clases y métodos de forma aislada antes de la ejecución real. Escribir tests reduce la necesidad de debug reactivo porque los errores se detectan durante el desarrollo.
STAD muestra estadísticas de ejecución de transacciones: tiempo de CPU, tiempo de BD, número de accesos a tablas y consumo de memoria, sin necesidad de un trace intrusivo que impacte el rendimiento.
Los formularios SAP tienen su propio debugger. Depurar un formulario requiere identificar si el error está en la función de impresión, en el formulario mismo o en los datos que recibe para generar el documento.
Además de ST22, SAP ofrece herramientas complementarias: el Application Log (SLG1) para errores controlados, el System Log (SM21) para errores de sistema y DUMPANALYSIS para análisis profundo de dumps.
Los procesos de actualización asíncrona en SAP se ejecutan en un proceso separado. Depurarlos requiere activar el debug de update task antes de ejecutar la transacción que lo dispara en el sistema.
Los SELECT ineficientes son la causa más frecuente de rendimiento pobre en ABAP. Conocer cuándo usar JOIN, FOR ALL ENTRIES o subselects, y cómo crear índices secundarios, es fundamental para cualquier desarrollador.
El Code Inspector y el ABAP Test Cockpit analizan automáticamente el código en busca de problemas de rendimiento, seguridad, sintaxis obsoleta y violaciones de las guías de desarrollo SAP del estándar.
Las ABAP CDS Views (Core Data Services) son la nueva forma de modelar datos en S/4HANA. Depurarlas requiere entender cómo se traducen a SQL de HANA y cómo los datos fluyen a través de las asociaciones.
Los servicios OData de SAP Gateway son la base de las apps Fiori. Depurar un servicio OData requiere analizar las peticiones HTTP, los métodos del data provider class y la capa de persistencia subyacente.
El ABAP RESTful Application Programming (RAP) model es el estándar de desarrollo en S/4HANA Cloud. Depurarlo requiere entender la arquitectura de behavior definitions, implementations y projections.
ABAP en SAP BTP (ABAP Cloud) tiene un conjunto reducido de sentencias y clases disponibles (el 'clean core ABAP'). Las técnicas de debugging difieren de las del ABAP on-premise clásico que conocemos.
El buffering de tablas en SAP acelera las lecturas almacenando los datos en la memoria del servidor de aplicaciones. Sin embargo, puede causar lecturas de datos obsoletos si los datos de la tabla cambian frecuentemente.
Los bloqueos en SAP (Enqueue) evitan que dos usuarios modifiquen el mismo registro simultáneamente. Cuando hay bloqueos colgados o errores de bloqueo, SM12 es la herramienta de diagnóstico principal.
Los jobs en background no pueden debuggearse de forma convencional. Existen técnicas especiales para depurar programas que se ejecutan en modo batch sin pantalla de usuario disponible.
Los problemas en ALV (ABAP List Viewer) como datos incorrectos, columnas que no muestran datos o errores al ordenar suelen tener su origen en el fieldcatalog o en la estructura de la tabla interna de datos.
Los SAP exits y customer exits (CMOD) permiten añadir lógica propia en puntos de exit del estándar sin modificarlo. Debuggearlos requiere activar el debugger en la función exit correspondiente.
El Batch Input (BI) y Call Transaction son técnicas de carga de datos en SAP. Cuando fallan es necesario analizar el log de sesión para identificar en qué pantalla y campo se produce el error de validación.
Las expresiones regulares en ABAP (FIND REGEX, REPLACE REGEX) permiten búsquedas y sustituciones de texto complejas. Depurar un regex que no funciona como se espera requiere herramientas específicas.
Los Test Seams (costuras de test) permiten insertar código de prueba en programas ABAP existentes sin modificar su estructura, facilitando el testing unitario de código legado que no fue diseñado para ser testeable.
La librería ABAP2XLSX permite generar ficheros Excel complejos directamente desde ABAP. Cuando la exportación falla o el formato no es correcto, el debugging requiere conocer la estructura de la librería.
La elección del tipo de tabla interna (STANDARD, SORTED, HASHED) tiene un impacto enorme en el rendimiento cuando la tabla tiene muchos registros. El SAT y ST05 ayudan a identificar el tipo óptimo para cada uso.
El dump TIME_OUT en SAP indica que un programa superó el tiempo máximo de ejecución configurado. Es uno de los dumps más frecuentes en programas con SELECT ineficientes o loops sobre grandes volúmenes.
La sentencia AUTHORITY-CHECK verifica que el usuario tiene los permisos necesarios antes de ejecutar una operación sensible. La transacción SU53 muestra el último authority-check fallido de cualquier usuario.
El nuevo ABAP (7.40+) incluye expresiones inline, el operador VALUE para inicializar tablas y estructuras, el operador CORRESPONDING para copiar campos y el operador REDUCE para agregaciones funcionales.
Los HANA Stored Procedures (SQLScript) permiten ejecutar lógica de negocio directamente en la base de datos. Depurarlos requiere herramientas específicas de HANA Studio o SAP HANA Cockpit.
El programming dinámico en ABAP (GENERATE SUBROUTINE POOL, creación dinámica de objetos con CREATE OBJECT) permite generar y ejecutar código en tiempo de ejecución, pero requiere especial cuidado en seguridad.
El Application Log (SLG1) es el mecanismo estándar de SAP para registrar mensajes de proceso de forma estructurada. A diferencia de los dumps de ST22, el log de aplicación captura información planificada.
SM50 muestra los procesos de trabajo activos en el servidor de aplicaciones actual. SM66 hace lo mismo para todos los servidores del sistema, permitiendo identificar procesos bloqueados o con alto consumo.
El análisis de buffers en SAP permite entender si las tablas principales están bien cacheadas en memoria o si se accede frecuentemente a la base de datos para cada lectura, impactando en el rendimiento general.
Las apps Fiori son aplicaciones web (SAPUI5). Depurarlas requiere herramientas del browser (Chrome DevTools) más que el debugger ABAP. Los errores pueden estar en el frontend o en el backend Gateway.
El dump ABAP_MEMORY_EXCEEDED indica que el programa ha superado el límite de memoria configurado. Es frecuente en programas que cargan grandes volúmenes de datos en tablas internas sin paginación.
Cuando un usuario recibe un error de autorización, SU53 muestra el ÚLTIMO authority-check fallido. SUIM (User Information System) permite analizar qué usuarios tienen qué roles y objetos de autorización.
SM58 muestra las transacciones RFC tRFC y qRFC que han fallado y están pendientes de reintento. Es fundamental para diagnosticar fallos en interfaces asíncronas entre sistemas SAP o con sistemas externos.
Clean Core en SAP es la filosofía de no modificar el estándar SAP usando BAdIs, RAP, CDS y APIs públicas. Mantener el Clean Core garantiza actualizaciones sin regresiones y cumplimiento con SAP Cloud.