viernes, 26 de diciembre de 2014

Guía de Procesos SAP MM: El Escenario de Subcontratación de Proveedores (Subcontracting)


Subcontratación de Vendedores.
 

El proceso de subcontratación de proveedores es un escenario logístico crítico y muy común en la industria manufacturera y de ensamblaje. Ocurre cuando una compañía (el cliente) diseña un producto pero delega la producción, ensamble o transformación física a un tercero experto (el proveedor subcontratista).

En este modelo, el cliente compra y suministra las materias primas o componentes necesarios al proveedor. El subcontratista ejecuta el proceso industrial, consume los componentes y entrega de regreso el producto terminado. El cliente solo paga al proveedor por el "servicio de maquila o ensamble".

Ejemplos Reales en la Industria

  • Sector Tecnológico: Una compañía diseña un teléfono inteligente a nivel global pero no posee plantas de fabricación. Compra las pantallas, procesadores y baterías a distintos fabricantes y los envía al almacén de un subcontratista, quien ensambla el teléfono móvil final y lo devuelve empaquetado.

  • Sector Automotriz: Una planta de vehículos adquiere bloques de acero y pistones, y los transfiere a un proveedor especializado para que realice el ensamble completo de los motores. Una vez listos, regresan a la línea de producción principal del fabricante de autos.

Flujo de Subcontratación Completo en SAP ERP / S/4HANA

A continuación, se detalla la secuencia de ejecución técnica, los tipos de movimientos de inventario y las transacciones estándar involucradas en SAP:

1. Creación de la Orden de Compra (Pedido)

El proceso inicia en la transacción ME21N. La clave para activar este escenario es asignar la Categoría de Posición "L" (Subcontratación) en la línea del documento.

  • Al ingresar el material terminado, el sistema explota de forma automática la Lista de Materiales (BOM) para determinar qué componentes se deben suministrar al proveedor. También es posible ingresarlos manualmente en el botón de "Componentes".

  • El precio neto indicado en el pedido corresponde exclusivamente al costo del servicio de ensamble (maquila).

  • Práctica recomendada: Mantener un Registro Info de Compras (Info Record) específico para la categoría de subcontratación, vinculando el material, el proveedor y el centro.

2. Suministro y Traslado de Materias Primas

Los componentes de la BOM deben despacharse desde el almacén propio hacia el stock especial del proveedor (Stock de subcontratación). Existen tres alternativas en SAP para registrar esta salida física:

  • ME20 / ME2ON (Monitor de Stock SC): Es la herramienta estándar y recomendada para monitorear el inventario pendiente de entrega. Permite generar la salida de mercancías con el tipo de movimiento 541.

  • MB1B / MIGO (Traspaso): Permite realizar el traslado manual utilizando el movimiento 541 (Traspaso a stock de material provisto al proveedor). El stock sigue perteneciendo a la compañía, pero cambia su estado a "vendedor".

  • MIGO (Directo con referencia): Envío directo de componentes haciendo referencia a la orden de compra si el proveedor de materia prima entrega directamente en el subcontratista.

3. Recepción del Producto Terminado e Impacto en Inventarios

Cuando el proveedor entrega el producto final (ej. el teléfono o el motor), se registra la entrada en la transacción MIGO utilizando la opción Entrada de mercancías por pedido (Tipo de movimiento 101).

Al contabilizar esta transacción, el sistema realiza una operación síncrona en dos posiciones dentro del mismo documento de material:

[MIGO: Entrada de Mercancías - Movimiento 101]
   │
   ├── Posición 1: Entrada del Producto Terminado ──────► Tipo Mov. 101 (Suma al stock propio)
   │
   └── Posición 2: Consumo Automático de Componentes ──► Tipo Mov. 543 (Resta del stock del proveedor)

📊 Impacto Contable: Si el material está valorado, esta transacción genera automáticamente el documento contable, donde se incrementa el valor del inventario de producto terminado, se da de baja el inventario de materias primas consumidas y se provisiona el costo del servicio de maquila (cuenta EM/RF).

4. Gestión de Rechazos, Desechos y Subproductos

Durante el proceso industrial es normal que ocurran pérdidas o sobrantes (por ejemplo, el 2% de desperdicio en pantallas o viruta de acero en el maquinado de piezas). SAP maneja este inventario residual de la siguiente manera:

  • Manejo de Desechos o Rechazos: Si el proveedor notifica un desecho mayor o menor al planificado en la BOM al momento de la entrega, se puede ajustar la cantidad de consumo en la MIGO. El sistema realiza un movimiento 545 en la ubicación del proveedor para registrar mermas o devoluciones. Si los componentes dañados se traen de vuelta a la planta, se utiliza el movimiento 542.

  • Tratamiento de Subproductos: Si el proceso genera un subproducto valioso (residuos reciclables, partes sobrantes utilizables), este se planifica en la BOM con cantidad negativa. Al recibir el producto terminado, el sistema ingresará automáticamente el subproducto al stock del proveedor con el movimiento 544 (o 545 dependiendo de la configuración), quedando disponible para ser retornado al centro propio con el movimiento 542.

5. Verificación de Facturas y Pago

El cierre del ciclo comercial e impositivo sigue el estándar del módulo logístico y financiero:

  • Recepción y Verificación de Factura: Se ejecuta en la transacción MIRO contra la orden de compra de subcontratación. Aquí se concilia el cobro que hace el proveedor estrictamente por el servicio de manufactura o ensamble prestado.

  • Gestión de Pago al Proveedor: El seguimiento de las cuentas por pagar y la posterior programación del pago se analiza y gestiona en el módulo de Finanzas (FI-AP) mediante el reporte de partidas abiertas en la transacción FBL1N.


lunes, 8 de diciembre de 2014

Como Visualizar las BADIS que se ejecutan en una transacción

1- Ingresar a la transacción SE80.

2- Seleccionar "Clase/Interface" y poner el nombre: "CL_EXITHANDLER" doble click en el método GET_INSTANCE.



3- Poner un break en:   CALL METHOD cl_exithandler=>get_class_name_by_interface y otro en uno de los When del Case del SY-SUBRC.



4- En la variable "exit_name" se verán las BADIS que se ejecutan en cada momento.

5- Visualizar las BADIS que encontré, usando la transacción SE18.

6- Para implementar la BADI que encontré se hace los siguiente:

6.1- Ingresar a la transacción SE19 y en BADI clásico pongo el nombre que encontré y le doy click al botón "Implementar", se diligencia el nombre iniciando con la letra  Z, a continuación se pide una descripción y listo

Como construir un WHERE dinamico en ABAP


1. Definir una variable tipo CHAR para almacenar las condiciones.

    lv_cond(72) TYPE c,

2. Definir una variable tipo tabla para adicionar la variable lv_cond.

    li_tab LIKE TABLE OF char72.

3. Validar si la variable esta asignada y adicionarla a las condicones

    IF lv_source IS NOT INITIAL.
        CONCATENATE '<campo>=' lv_source  INTO lv_cond SEPARATED BY space.
        APPEND lv_cond TO li_tab.
    ENDIF.

martes, 28 de octubre de 2014

Como crear su propio rango de Números (SNRO)

Es usual que cuando se genera una factura, esta haga referencia a un número único, hecho que se convierte en un elemento especifico para identificar la factura.
 
SAP permite la creación y administración de los rangos de número disponiendo de las transacciones SNRO para la creación del objeto y la definición de los rangos de número y dentro de los programas se utiliza la función NUMBER_GET_NEXT para incrementar el número actual al siguiente número del rango.
 
Para crear un rango de número los pasos son los siguientes:

  • Ingresar a la transacción SNRO.
  • Ingresar el nombre del rango de Número y Click en crear.
  • Ingresar el dominio, tipo de datos y descripción asociada al rango de números.
  • Implementación del rango de número.
 
  • Definir el rango de número por sociedad dado el caso que se haya establecido así.
 
 
  • Definir el rango de numero y asignar el consecutivo.

jueves, 23 de octubre de 2014

Como extender las vistas del maestro de materiales usando la MM50

Prerrequisitos:
Si una de las vistas del maestro de materiales no se esta visualizando cuando se ingresa a la transacción MM50, entonces usted deberá hacerla visible seleccionando la vista a traves de la transacción OMS2.
 
Ejemplo:
Para el material HALB la vista de ventas no debería ser visualizada para extenderla ni en la transacción MM01 ni en la MM50, por lo que generalmente las personas no la deberían seleccionar en la transacción OMS2 para el material HALB.
En este caso lo que requerimos ir a la transacción OMS2, luego dar doble click en el tipo de material respectivo, en este caso HALB y luego seleccionar la vista que desea visualizar.


Nota: El número del material debería ser mantenido para que tenga todos los datos básicos y vistas(Datos Básicos 1, Datos Básicos 2 and Datos de Etiqueta) que sean requeridos.
 
  1. Tomar la lista de materiales y utilizarla para limitar los registros.
  2. Seleccione las vistas que desea extender, por ejemplo 'V' es para ventas.
  3. Ejecute la transacción.
Paso 1:
  • Seleccione estado de mantenimiento.
  • Ingrese el numero de material.
  • Ejecutar
 
 
Paso 2:
Haga Click en el botón seleccionar todo para hacer la selección y a continuación click en 'Mantenimiento de Materiales', presione el botón para continuar.


Paso 3:
Una vez haya seleccionado los materiales, haga Click en

Paso 4:
Ingrese los datos que serán modelo para la extensión masiva de materiales

Paso 5:
Actualizar los materiales seleccionados

Paso 6:
Actualizar los datos obligatorios dependientes de la vista que este extendiendo para el material y guarde la información.
 

domingo, 19 de octubre de 2014

Pruebas de Software en SAP

El diseño de pruebas de software en SAP es el mismo que el utilizado para probar cualquier otro software, por lo que se tienen los siguientes tipos de pruebas:
 
Pruebas de Integración :
Las pruebas de integración, son desarrolladas cuando se adiciona código a una base de código existente; por ejemplo cuando se adiciona un nuevo modulo de función a un grupo de funciones. 
Las pruebas de integración miden la forma en que este código se integra y trabaja con el código existente, verificando entonces la forma en la cual se comportan las variables de entrada y salida, el formato de datos y como se manipulan las variables.
 
Pruebas de Regresión:
Cuando hablamos de pruebas de regresión, podemos hablar en dos formas, la primera hace referencia cuando un problema existente en el código ha sido corregido, por lo que una prueba de regresión permite verificar que el defecto haya sido solucionado; esto evita que posteriormente pueda volver a encontrarse el mismo defecto.
En una segunda instancia, una prueba de regresión es la contraparte de una prueba de integración, cuando el código se adiciona, es aquí donde la prueba de regresión verifica que el código existente trabaje correctamente cuando se haya adicionado el nuevo código, garantizando que el existente no se haya dañado.

Como crear una BTE en SAP

En este caso tomaremos como ejemplo la creación de una BTE para la visualización de la Fecha Valor (Campo VALUT) en la transacción FBL5N.

1. Ingresar a la transacción FIBF

2. Seleccionar




3. Especifique el nombre del producto


4. Identifique el evento asociado a la transacción y tome como base el modulo de función.

5. Active el modulo de función

jueves, 16 de octubre de 2014

El Consultor de Sistemas como Arquitecto de Valor: Superando la Parametrización para Liderar la Transformación de Negocio

En la economía del conocimiento, el término "consultor" ha ganado un protagonismo innegable, pero su ejecución en el sector tecnológico suele desvirtuarse. Si revisamos la definición clásica, un consultor es un estratega que provee consejo experto en un dominio específico. Sin embargo, en la industria de TI hemos permitido que este rol se reduzca de facto a un ejercicio puramente operativo: parametrizar un sistema, configurar módulos o picar código de forma aislada.

El verdadero consultor de sistemas entiende que la tecnología no es el fin, sino el medio. Limitarse a replicar funcionalidades y acatar de manera ciega los requerimientos del cliente es abdicar de nuestra responsabilidad. Nuestro propósito fundamental es actuar como agentes promotores del cambio, conectando el software con la optimización de los procesos empresariales y liderando activamente la gestión cultural de la organización.

1. El Costo de la Automatización Ciega (Gobernanza vs. "Tomar Pedidos")

Cuando un equipo de consultoría se limita a automatizar un proceso ineficiente sin cuestionarlo, solo logra que la empresa cometa errores a una velocidad mucho mayor. Los grandes desastres en implementaciones tecnológicas rara vez ocurren por fallas en el código; ocurren por una desconexión absoluta entre el software y la estrategia transversal del negocio.

Las decisiones técnicas no pueden tomarse en silos, ni verse limitadas exclusivamente por presupuestos de corto plazo o por la inexperiencia de gerencias que ignoran el impacto arquitectónico.

Caso Real: La famosa migración fallida de Lidl en 2018. La cadena de supermercados canceló un proyecto de implantación de SAP (después de haber invertido cerca de 500 millones de euros y 7 años de trabajo) porque intentaron modificar el software estándar para adaptarlo a sus procesos tradicionales de inventario, en lugar de utilizar la consultoría para transformar sus procesos internos y adoptar las mejores prácticas del sistema. Un enfoque de consultoría proactivo habría priorizado la gestión del cambio sobre el desarrollo a medida a gran escala.

2. La Trampa del "Efecto Marca" y el Enfoque Adaptativo

Un error recurrente en la gobernanza corporativa es creer que adquirir la marca líder del mercado (el cuadrante superior de Gartner, el ERP más costoso o la suite en la nube de moda) solucionará mágicamente los problemas de fondo de la compañía. Las empresas compran el referente del mercado ignorando sus propias variables básicas, su madurez digital y su capacidad de absorción del cambio.

El consultor estratégico orienta al cliente para que evalúe sus decisiones bajo tres pilares fundamentales antes de firmar un contrato:

DimensiónEnfoque Tradicional (Mecánico)Enfoque Proactivo (Estratega)
Alineación de ProcesosModificar el software para que se parezca al caos actual del cliente.Rediseñar el proceso bajo estándares de industria (Out-of-the-box) antes de configurar.
Madurez TécnicaAdoptar herramientas hipercomplejas para las que el equipo interno no está preparado.Diseñar una hoja de ruta (Roadmap) evolutiva, asegurando la adopción técnica gradual.
Gobernanza FinancieraEvaluar solo el costo de la licencia inicial (CapEx).Analizar el Costo Total de Propiedad (TCO) y el Retorno de Inversión (ROI) a mediano plazo.

3. Propuesta de Acción: El Consultor como Catalizador y Líder de TI

Para revertir esta tendencia y asegurar el éxito de los proyectos de sistemas, la consultoría moderna debe operar bajo principios propositivos bien definidos:

  • Co-diseño de Soluciones (Business-IT Alignment): El consultor debe sentarse con los dueños del proceso (Finanzas, Logística, Operaciones), no solo con el área de TI. El objetivo es entender el dolor del negocio para proponer la arquitectura técnica óptima.

  • Gobernanza Tecnológica Transversal: Evitar parches y desarrollos satélites innecesarios. Diseñar sistemas integrados, escalables y con un núcleo limpio (Clean Core), facilitando futuras actualizaciones sin romper la operación.

  • Liderar la Gestión del Cambio: Todo despliegue técnico debe ir acompañado de una estrategia de capacitación, adopción y empatía con el usuario final. Si el usuario rechaza la herramienta, la inversión técnica es igual a cero.

Caso Real de Éxito: Las implementaciones logísticas de Amazon o la reestructuración operativa de Target en su transición omnicanal. Estas compañías no triunfaron por el software en sí, sino porque sus arquitectos y consultores rediseñaron la cadena de suministro completa de forma transversal, utilizando APIs e integraciones robustas para conectar cada decisión técnica con la experiencia del cliente final y la eficiencia financiera del negocio.

La excelencia en la consultoría de sistemas se alcanza cuando dejamos de ser vistos como un centro de costos técnico y pasamos a ser reconocidos como los arquitectos del crecimiento y la ventaja competitiva de la organización.


 
 
 

jueves, 25 de septiembre de 2014

Guía de Configuración en SAP FI-AA: Parámetros Clave y Transacciones de Parametrización

En el módulo de Contabilidad de Activos Fijos (FI-AA), la correcta definición de los parámetros globales es el cimiento para asegurar una depreciación exacta, reportes financieros fiables y un cumplimiento estricto de las normas contables locales e internacionales (como las NIIF/IFRS).

La mayoría de los parámetros estructurales y de control de este módulo pueden ser creados y modificados haciendo uso de las siguientes transacciones clave del Customizing:



 

1. Transacción ORFA: El Menú de Configuración General de Activos Fijos

La transacción ORFA es, en realidad, el acceso directo al árbol de la guía de implementación (IMG) exclusivo para Activos Fijos. En lugar de navegar por toda la transacción SPRO, ORFA te sitúa directamente en el corazón de FI-AA.

Desde este menú estructurado, un consultor o administrador del sistema puede parametrizar:

  • Estructuras Organizativas: Definición y asignación de los planes de valoración (Chart of Depreciation), que agrupan las reglas de depreciación de una o varias sociedades.

  • Clases de Activos Fijos (Transacción OAOA): El enlace principal entre el maestro de activos fijos y la contabilidad de mayor (FI-GL). Aquí se define el rango de números y la asignación de cuentas.

  • Áreas de Valoración (Transacción OADB): Configuración de las diferentes "capas" de cálculo de amortización (por ejemplo, Área 01 para Libros Locales, Área 30 para IFRS/NIIF, Áreas Fiscales, etc.).

2. Transacciones Clave Complementarias para la Operación de FI-AA

Para complementar el uso de la ORFA, existen transacciones específicas que todo consultor de sistemas y analista contable de activos fijos debe dominar para la parametrización diaria:

A. Métodos y Claves de Amortización (Transacción AFAMA)

Las claves de amortización dictan la matemática exacta de cómo el sistema desgastará el valor del activo a lo largo de su vida útil. Mediante la AFAMA, se configuran y activan estas claves, combinando los métodos de cálculo básicos, de periodos y de fin de amortización.

B. Determinación de Cuentas (Transacción AO90)

Es uno de los puntos de integración más críticos entre FI-AA y FI-GL. En la AO90, se parametrizan las cuentas de balance (adquisición, producción, revalorización) y las cuentas de resultados (gastos de amortización y amortización acumulada) para cada clase de activo fijo y área de valoración.

C. Variantes de Pantalla y Reglas de Estructuración (Transacción AOLA)

Controla qué campos son obligatorios, opcionales, visualizables o invisibles al momento de crear un dato maestro de activo fijo (a través de la transacción AS01). Esto evita errores humanos de introducción de datos por parte de los usuarios operativos.

3. Consideraciones de Arquitectura en Entornos S/4HANA

Si estás administrando o configurando el sistema en entornos modernos de SAP, debes tener en cuenta que la arquitectura de activos fijos evolucionó hacia la Nueva Contabilidad de Activos Fijos (New Asset Accounting):

💡 El Impacto en S/4HANA: Aunque la transacción ORFA sigue siendo el punto de partida para la configuración, la integración con el Diario Universal (ACDOCA) elimina la necesidad de transacciones de reconciliación clásicas (como la ABST2). Ahora, la contabilización de la depreciación (transacción AFAB) escribe directamente en tiempo real en la contabilidad general para todos los principios contables definidos en los ledgers paralelos.

Conclusión

El uso estratégico de la transacción ORFA optimiza el tiempo de implementación y mantenimiento de la estructura financiera de la empresa. Conocer a fondo este mapa de parametrización asegura que el ciclo de vida completo del activo fijo —desde su alta o capitalización inicial, pasando por su amortización mensual, hasta su baja o desincorporación— esté perfectamente automatizado y alineado con los objetivos del negocio.

 

sábado, 20 de septiembre de 2014

Como corregir el error SoapUI JVM Maximum Heap Siz

soapUI es una herramienta muy útil y justamente esta es la razón por la cual se ha convertido en mi herramienta favorita para probar servicios web.
 
En una de mis ejecuciones de esta herramienta he apreciado que esta no ha querido iniciar el aplicativo y he obtenido el siguiente error: "soapUI JVM maximum heap size (-Xmx) error message"
 
The JVM could not be started. The maximum heap size (-Xmx) might be too large or an antivirus or firmware tool could block the execution.
 

Solución

El problema Java maximum heap size (-Xmx) ocurre cuando Soap UI intenta obtener la cantidad de memoria en un solo bloque y esta no se encuentra disponible.

Paso #1. Diríjase a la ruta “C:\Program Files\SmartBear\soapUI-x.x.x\bin” en su sistema y localice el archivo  soapUI-x.x.x.vmoptions.
Donde x.x.x corresponde a la versión e Soap UI que usted utilice

soapUI Java Heap Memory Issue - soapUI-4.5.2.vmoptions
Paso #2. Ahora haga click derecho en el archivo y ábralo usando el editor de texto de su preferencia

soapUI Java Heap Size Issue - edit soapUI-4.5.2.vmoptions

Una vez lo abra, observará que el archivo luce de la siguiente manera:
-Xms128m
-Xmx1000m
-Dsoapui.properties=soapui.properties
-Dsoapui.home=C:\Program Files (x86)\SmartBear\soapUI-4.5.2/bin
-Dsoapui.ext.libraries=C:\Program Files (x86)\SmartBear\soapUI-4.5.2/bin/ext
-Dsoapui.ext.listeners=C:\Program Files (x86)\SmartBear\soapUI-4.5.2/bin/listeners
-Dsoapui.ext.actions=C:\Program Files (x86)\SmartBear\soapUI-4.5.2/bin/actions
-Dwsi.dir=C:\Program Files (x86)\SmartBear\soapUI-4.5.2/wsi-test-tools
-Djava.library.path=C:\Program Files (x86)\SmartBear\soapUI-4.5.2/bin
-Djava.util.Arrays.useLegacyMergeSort=true
-Djxbrowser.xulrunner.dir=C:\Program Files (x86)\SmartBear\soapUI-4.5.2\.JxBrowser
Reduce el valor de  -Xmx a uno mas pequeño tal como 512m.

Paso #3. Guarde el archivo soapUI-x.x.x.vmoptions y ejecute el archivo soapUI.exe.

Versión Original:
http://quicksoftwaretesting.com/soapui-jvm-heap-size-xmx-error/

MRP Para algunos materiales - Ampliación M61X0001

SAP provee la funcionalidad MRP a nivel de planta (MD01) y a nivel de material (MD02/MD03). Dependerá de la implementación si se debe realizar la ejecución para una planta o para un conjunto especifico de materiales. 
 
Utilizando la ampliación  M61X0001

SAP provee la ampliación M61X0001. Esta puede ser verificada e implementada haciendo uso de la transacción SMOD



Una vez lo haga, seleccione la opción componentes.

Esta presentará dos módulos de función para los Exits:
  • EXIT_SAPLM61C_001 
  • EXIT_SAPMM61X_001

Double click uno de los modulos de función y visualice la lista de objetos (Ctrl+Shift+F5)
 
Una vez hecho esto, dentro del exit, en este caso el EXIT_SAPMM61X_001 encontrará el include ZXM61U01. Es en este lugar donde deberá incluirse el código. 
 
A continuación se ilustra un ejemplo del programa dentro del éxit. 

============================================

Function EXIT_SAPLM61C_001
*----------------------------------------------------------------------*
* INCLUDE ZXM61U02 *
*----------------------------------------------------------------------*
* PLEASE NOTE: this code must be identical to ZXM61U01.
CLEAR: NO_PLANNING, STOP_PLANNING.
CASE USER_KEY.
*----------------------------------------------------------------------*
* select materials for one MRP controller (specified in user_par)
*----------------------------------------------------------------------*
WHEN '001'.
UXPAR = USER_PAR.
CONDENSE UXPAR.
WRITE UXPAR+0(3) TO DISPO.
IF DISPO IS INITIAL.
EXIT.
ENDIF.
IF MT61D-DISPO <> DISPO.
NO_PLANNING = 'X'.
ENDIF.
ENDCASE.


Function EXIT_SAPMM61X_001
*----------------------------------------------------------------------*
* INCLUDE ZXM61U01 *
*----------------------------------------------------------------------*
* PLEASE NOTE: this code must be identical to ZXM61U02.
CLEAR: NO_PLANNING, STOP_PLANNING.
CASE USER_KEY.
*----------------------------------------------------------------------*
* select materials for one MRP controller (specified in user_par)
*----------------------------------------------------------------------*
WHEN '001'.
UXPAR = USER_PAR.
CONDENSE UXPAR.
WRITE UXPAR+0(3) TO DISPO.
IF DISPO IS INITIAL.
EXIT.
ENDIF.
IF MT61D-DISPO <> DISPO.
NO_PLANNING = 'X'.
ENDIF.
ENDCASE.

martes, 17 de junio de 2014

Logging on without being authorized

Client 066 usually exists in a SAP system due to EarlyWatch services.
Often this client does not have master users. If it is true, anyone can log into the system using the client 066,


user SAP*
password PASS.

lunes, 16 de junio de 2014

Tablas SAP - Modulo MM

SAP MM

1. Maestro de proveedores
TablaDescripciónComentario
LFA1Datos maestros
LFB1Proveedores por sociedad
LFB5Datos de reclamación
LFBKBancos/cuentas
LFC1Cifras de movimientos
LFC3Cifras de movimientos CME
LFM1Datos de la organización de compras


2. Documentos de compras
TablaDescripciónComentario
EKKOCabecera del doc. de comprasContiene el tipo de documento
EKPOPosición del doc de compras
EKETRepartos del plan de entregas
EKESConfirmaciones de pedido
EKKNImputación en el documento
EKANDirección del proveedor en el doc. de compras
EKBEHistorial para el doc.
EKUBÍnidce de pedidos para traslado de material
MDUBVista de lectura sobre pedido de traslado para toma-pedido
MDBSVista de material en posición de pedido/reparto



3. Solicitud de pedidos
TablaDescripciónComentario
EBANSolicitud de pedio por posición
EBKNImputación de solicitud de pedido



4. Libro de pedidos
TablaDescripciónComentario
EORDLibro de pedidos de compras



5. Registro info de compras
TablaDescripciónComentario
EINADatos generales
EINEDatos de la organización de compras
KONPCondiciones
EIPAHistorial del precio del pedido del registro info

Tablas SAP - Modulo SD

TABLAS SD

1. Maestro de clientes
TablaDescripciónComentario
KNA1Datos maestro de clientes
KNB1Clientes por sociedad
KNBKBancos/cuentas
KNVALugares de descarga
KNVKPersona contacto (interlocutor)
KNVPFunciones de interlocutorEl campo PARVW diferencia entre los distintos interlocutores
KNVSDatos de expedición
KNVVDatos de comercial
KNVKInterlocutor (personas de contacto)



2. Documentos comerciales
TablaDescripciónComentario
VBUKStatus cabecera y datos de gestión
VBUPStatus de posición
VBFAFlujo de doc. comerciales
VBPAInterlocutor



3. Pedidos de ventas
TablaDescripciónComentario
VBAKCabecera
VBAPPosición
VBFAFlujo de doc. comerciales
VBKDDatos comerciales
VBEPDatos de reparto



4. Entregas
TablaDescripciónComentario
LIKPDatos de cabecera
LIPSDatos de posición
LQUACuantos/almacenaje

5. Estructura de organización
TablaDescripciónComentario
TVKOOrganizaciones de ventaVista V_TVKO_LK
TVKOTTextos org. Ventas
TVKOVCanales de distribución por org. de ventasVista V_TVKOV_LK
TVKOSSectores pro org. de ventasVista V_TVKOS_LK
TVTAÁreas de ventasVista V_TVTA_LK
TVKBZOficina de ventas por área de ventasVista V_TVKBZ_LK
TVBVKGrupo vendedores por oficina de ventasVista V_TVBVK_LK
TVKWZCentros por org. de ventasVista V_TVKWZ_LK
TVSWZLugares de expedición por centroVista V_TVSWZ_LK
T001K
Vista V_T001K



6. Facturas
TablaDescripciónComentario
VBRKDatos de cabecera
VBRPDatos de posición



7. Índice de ventas
TablaDescripciónComentario
VAKPAPedidos por función interlocutor
VAPMAPosiciones pedido por material

8. Necesidades de ventas
TablaDescripciónComentario
VBBERegistro individual de necesidad de ventas