Truco 100. Consigna de cliente en ventas. Gestionar stock por destinatario de mercancía.


Hoy estamos de aniversario. Cumplimos nuestro truco número 100 y ya casi 9 años desde aquel 7 de noviembre de 2010 cuando escribí mi primera entrada en este blog. Ha llovido un poco, la verdad.

Lo que empezó siendo un blog de notas personal sobre SAP fue tomando vida durante estos años, ganando contenido, haciendose mayor al fin y al cabo. Muy orgulloso de él y de que me haya permitido conocer muchas cosas de este sistema y a muchísima gente por todas las empresas por las que he pasado durante los últimos tiempos. Todo un placer haberlo compartido con vosotros.

En nuestro truco de hoy volvemos a temas más funcionales, en concreto del modulo de SD y vamos a hablar de la funcionalidad de consigna de cliente.

Como muchos de vosotros sabéis, en la funcionalidad que Sap tiene disponible en el módulo de SD podemos gestionar los procesos donde nosotros cedemos stock sin cargo a los clientes (el stock sigue perteneciendo al vendedor). Cuando el cliente notifica el consumo de los stocks, se realiza la correspondiente facturación y descuento de esos stocks especiales (stock W).

De forma resumida podéis ver en la siguiente imagen las diferentes operativas disponibles por estándar en la funcionalidad de consigna:

Básicamente, los flujos de consigna consisten en las siguientes clases de documento, cada uno de ellos con el siguiente cometido:

  • Pedido KB – Reposición de artículos en consignación: nos permite realizar la entrega de stock en deposito al cliente. Es un pedido sin precio, y el proceso comercial termina en la entrega, traspasándose el stock de libre utilización al stock de consigna (W), asociado al solicitante. No hay facturación.
  • Pedido KE – Toma de artículos en consignación: cuando el cliente nos notifica los consumos del stock de consigna, se genera un documento de este tipo. Nos permite consumir el stock W mediante la entrega y realizar la facturación al cliente de los productos de consigna utilizados.
  • Pedido KA – Recogida de artículos en consignación: si el cliente nos devuelve el stock en consigna sin haberlo consumido, utilizaremos este circuito. Con la entrega daremos de baja el stock W y lo devolveremos a stock de libre utilización en nuestro almacén. Tampoco hay factura ni precio en este caso.
  • Pedido KR – Retorno de artículos en consignación: nos permite gestionar la devolución a stock de consigna de un stock previamente consumido. La entrega hace la entrada de stock en stock W, y nos permite abonar al cliente los stocks devueltos (si hay facturación).

Los stocks asociados a la consigna (stock especial W), se pueden consultar con las transacciones clásicas de gestión de stocks (MB52 o MMBE).

También podéis utilizar de forma concreta solo para dicho tipo de stock la transacción MB58.

Los stocks en consigna se encuentran en la instalación del cliente, pero a nivel contable siguen perteneciendo a nuestra empresa, aunque en estos informes de stocks los veremos sin almacén asociado (no están en nuestra ubicación), y siempre asociados a un stock especial W, con identificador el número de cliente (por ejemplo, como vemos en la MB52)

Por defecto, Sap utiliza el solicitante de los pedidos (función de interlocutor AG) para identificar el stock especial asociado a los procesos de consigna.

Aquí es donde vamos a hablar de nuestro truco de hoy. Si necesitáis que los stocks se gestionen asociados a cada uno de los destinatarios de mercancía, podremos hacerlo utilizando funciones de interlocutor especiales. Pensar en el caso de un cliente retailer, con un conjunto de tiendas, donde queremos gestionar de forma separada el stock entregado en cada tienda (en lugar de gestionar de forma general al cliente).

La solución es tan sencilla como utilizar en nuestros documentos de consignación la función de interlocutor SB Respons. stock espec., que deberá de tener el mismo valor en el documento que la función de interlocutor WE Destinatario de mercancía.

Cuando realicemos la entrega, la función de interlocutor SB viajará a la entrega y será tenida en cuenta en el momento de generar los documentos de material. Todos los movimientos de stock especial W utilizarán dicho interlocutor en lugar del solicitante.

La función de interlocutor SB se podrá indicar en los datos maestros del cliente para que sea propuesta al crear los pedidos.

Para el correcto funcionamiento del circuito, habrá que permitir la función de interlocutor en los esquema de interlocutor de los grupos de cuenta (cliente) o documentos de ventas y entregas. Igualmente, habrá que autorizar al grupo de cuentas del cliente el poder desempeñar la función de interlocutor SB (ver bibliografía con todos los detalles de parametrización necesarios).

Bibliografia:

Special Stock Partner for Consignment Stock and Returnable Packing based on Ship-to Party Partner | SAP Blogs

Espero que disfrutéis el truco y !Feliz cumpleaños!.

Publicado en Formacion, Sap SD | Etiquetado , , , | 8 comentarios

Truco 99. Desbloquear variantes de selección creadas por otro usuario.


En nuestro truco de hoy vamos a hablar de como desbloquear variantes de selección que haya creado otro usuario (y bloqueado), y que necesitemos modificar (seguramente el usuario ya no estará en la empresa).

Antes de eso, vamos a hablar un poco de las variantes de selección y a ver que comos podemos hacer con ellas.

Como todos sabéis, en cualquier report abap en el que se puedan indicar criterios de selección, Sap nos ofrece la opción de grabar esos criterios de selección en forma de variante, para su posterior reutilización en el mismo programa o para planificar jobs de fondo que utilicen esos mismos criterios de filtrado o selección.

Las variantes se salvan con el botón grabar en la pantalla inicial de los programas y se pueden recuperar como vemos en la imagen previa. Al grabar, podemos configurar las siguientes propiedades de la variante:

  • Indicar valores para la selección: valores individuales o intervalos incluidos o excluidos, uso de comodines en la selección (*, etc).
  • Proteger la variante: para evitar que cualquier usuario aparte del creador pueda modificarla.
  • Restringir su uso solo para procesos de fondo.
  • Proteger campos: evitar que se pueda modificar el valor indicado en un campo en la variante.
  • Suprimir campos: eliminar de la visualización campos de la pantalla o el botón para selección múltiple.
  • Grabar campo sin valores: forzamos a que un campo determinado se grabe en la variantes sin valores de selección, pese a que tuviéramos valores indicados en el campo.
  • Desactivar GPA: forzar a que no se tomen de la memoria de usuario los campos que se hayan programado de estas manera (funcionalidad SET/GET).
  • Campo obligatorio: hacer requerido para el usuario que se introduzca algún valor en el campo.
  • Uso de variables de selección en los campos fecha: se puede trabajar con variables de fecha dinámica, que nos inicializaran el contenido del campo al utilizar la variante (en el momento de recuperarla).

Por ejemplo, podremos indicar la fecha del día actual, fecha del día +/- número de días, primer dia del mes actual o anterior, ultimo día del mes actual o anterior, primer día del próximo mes, primer día laboral del mes actual (utilizando calendarios de la SCAL), etc.

Esto nos permite personalizar la ejecución de programas donde se utilizan campos de fecha (por ejemplo, la transacción MMPV para realizar el cambio de periodos contables de MM, que se podrá planificar con un job de fondo para realizar el cambio de periodo el día 1 de cada mes).

Todas estas opciones se podrán indicar en el momento de grabar la variante.

En el caso de que necesitéis gestionar variantes ya creadas, os recomiendo las siguientes utilidades:

  • Desbloquear variantes creadas por otro usuario: no es necesario copiar la variante con otro nombre para poder hacerlo. Bastará con utilizar el report RSVARENT.
  • Transporte de variantes entre sistemas: en ocasiones necesitamos llevarnos las variantes de un sistema a otro. No es necesario crearlas manualmente, podéis utilizar el report RSTRANSP. El sistema nos pedirá el report y las variantes a transportar, y tras seleccionar las deseadas, nos pedirá la orden de transporte para llevarlas de un sistema a otro.
  • Modificación de los valores de las variantes: todas las variantes se pueden gestionar desde la misma transacción SE38, con la opción VARIANTES.

Desde aquí podremos modificar tanto los valores de la variante, como los atributos detallados. Si necesidad de acceder a la ejecución del programa para realizar el cambio de valores o variables asociadas a la variante.

Espero que os sea de utilidad. Nos acercamos al truco 100 y os adelanto que la primavera va a venir este año cargada de nuevos trucos y muchas novedades en el blog.

Bibliografía:

https://itsiti.com/no-authorization-to-change-sap-variant

Publicado en Abap, Productividad, Sap Basis | Etiquetado , , , | Deja un comentario

Truco 98. Ampliación de los informes de compras (ME??) con nuevos campos.


Hoy vamos a hablar de una clásica necesidad en la mayoría de proyectos o durante el soporte a una instalación Sap ya en funcionamiento. Anteriormente, los informes de compras eran difícilmente ampliables, a no ser que utilizaremos algún tipo de enhacement o copia de los informes estándar. Eso hacia complicado el cubrir requerimientos de usuario para añadir nuevas columnas en los resultados de los diferentes informes de compras.

Por ejemplo, en los informes:

  • Informes de registros info: ME1L, ME1M.
  • Informes de pedidos: ME2*.
  • Informes de contratos marco (pedidos abiertos, planes de entrega): ME3*.
  • Informes de solicitudes de pedido: ME5A, ME5K.
  • Liberación colectiva de documentos: ME55 para solicitudes de pedido, ME28 para pedidos o ME35 para otros documentos de compra.
  • Informes de libros de pedido (ME0M) o regulación por cuotas (MEQM)
  • Historial de precios de pedido (ME1P).
  • Informes de ofertas: ME4L, ME4M, etc.

A partir de la versión 6, EhP4, Sapp pone a disposición de los clientes la BADI ME_CHANGE_OUTTAB_CUS para poder personalizar todos estos informes estándar.

Con la badi podemos intervenir en los datos que se visualizan en los ALV de estas transacciones, de la siguiente manera:

  • Cambiar la información estándar que se determina en los informes (por ejemplo, proveedor, material).
  • Mostrar información estándar adicional, de los documentos o datos maestros.
  • Mostrar campos de cliente.
  • La BADI no se llama en las siguientes transacciones: ME80* ( ME80FN, ME80RN) ni en las ME56, ME57, ME58 o ME59N (transacciones para el tratamiento de las solicitudes de pedido y la conversión automática a pedido).

Requerimientos:

Habria que activar la business function LOG_MMFI_P2P ( MM, Integration of Materials Management and Financial Accounting), aunque de mi experiencia os puedo decir que he podido utilizar la badi sin activar la BF y funciona.

Ademas, es necesario utilizar en todas las transacciones indicadas la visualización ALV (se define en la parametrización, asociada a los Alcances de la lista).

En la parametrización se indica por el código de alcance si se utiliza la visualización ALV por defecto.

Igualmente, es un requisito utilizar el parámetro ME_USE_GRID = X, que fuerza la visualización ALV en las transacciones donde no se puede indicar un alcance de lista (por ejemplo, en la ME1L o ME1M).

La BADI no esta disponible en versiones inferiores a la EhP4 ni puede ser bajada a versiones inferiores. No es dependiente de filtro y se puede realizar múltiples implementaciones de ella (se ejecutarán todas). Por ejemplo, podríamos hacer una implementación por transacción que queramos ampliar.

No esta activa por defecto en el sistema.

Ejemplo de Implementación.

En nuestro ejemplo, vamos a ampliar el listado de pedido (ME2X) con varios campos del pedido que son útiles para los usuarios de mi sistema y que no se muestran por defecto. También podríamos haberlo hecho en el informe de liberación colectiva de pedidos (ME28).

Crearemos una implementación de la BADI ME_CHANGE_OUTTAB_CUS utilizando la transacción SE18.

SCN1.png

La BADI solo tiene un método, llamada FILL_OUTTAB, que recibe la siguiente información:

  • Nombre de la estructura: en la variable IM_STRUCT_NAME. En este campo recibiremos diferentes valores según la transacción en la que nos encontremos (por ejemplo, MEREP_OUTTAB_PURCHDOC_REL para los informes de liberación colectiva de pedidos; MEREP_OUTTAB_PURCHDOC para los informes de pedidos, ofertas o contratos ; MEREP_OUTTAB_EBAN para los informes de solpeds; MEREP_OUTTAB_INFREC para los informes de registros info; EORD para los informes del libro de pedidos; MEREP_OUTTAB_QUOTA para regulación por cuotas; MEREP_OUTTAB_PRHIS para el historial de precios de pedido (transacción ME1P) , etc)
  • Información a mostrar en los resultados del informe: en la tabla interna CH_OUTTAB. Para hacer el tratamiento de la tabla habrá que declarar un field-symbol con la estructura indicada en IM_STRUCT_NAME.

En la implementación de la BADI incluiremos el código personalizado para el llenado de los campos estándar.

En el caso de querer añadir campos en los resultados (tanto estándar que no se muestran como campos de cliente), tendremos que ampliar la estructura de datos correspondiente con un append en la transacción SE11. En nuestro ejemplo, hemos añadido 3 campos estándar y una campo Z.

Si los campos están en las tablas estándar, se llenará automáticamente en la estructura sin hacer nada. En caso contrario, habrá que realizar la lógica de llenado.

Os pego el ejemplo del código utilizado para el ejemplo indicado:

 METHOD if_ex_me_change_outtab_cus~fill_outtab.
* ampiacion campos ALV me2....

  DATA: ls_ekko TYPE ekko.

  FIELD-SYMBOLS: <fs_outtab>   TYPE any,
                 <fs_ebeln>    TYPE ebeln,
                 <fs_ebelp>    TYPE ebelp.
  FIELD-SYMBOLS:   <fs_zzaedat> TYPE datum.
  

* check that a purchasing document view is displayed
 CHECK im_struct_name EQ 'MEREP_OUTTAB_PURCHDOC'.

* loop at the output table and assign a field symbol
  LOOP AT ch_outtab ASSIGNING <fs_outtab>.

*-- assign the purchasing document number to a field symbol
    ASSIGN COMPONENT 'EBELN' OF STRUCTURE <fs_outtab> TO <fs_ebeln>.
    CHECK sy-subrc = 0.
*-- assign the purchasing document item number to a field symbol
    ASSIGN COMPONENT 'EBELP' OF STRUCTURE <fs_outtab> TO <fs_ebelp>.
    CHECK sy-subrc = 0.

   ASSIGN COMPONENT 'ZZAEDAT' OF STRUCTURE <fs_outtab> TO <fs_zzaedat>.
    CHECK sy-subrc = 0.
    CLEAR <fs_zzaedat>.

    CALL FUNCTION 'ME_EKKO_SINGLE_READ'
      EXPORTING
        pi_ebeln                  =  <fs_ebeln>
*   PI_BYPASSING_BUFFER       =
*   PI_REFRESH_BUFFER         =
     IMPORTING
       po_ekko                   = ls_ekko
     EXCEPTIONS
       no_records_found          = 1
       OTHERS                    = 2
              .
    IF sy-subrc = 0.
      <fs_zzaedat> = ls_ekko-aedat.
    ENDIF.
 ENDLOOP.
ENDMETHOD.

Al ejecutar las transacciones de listado de pedidos (ME2L, ME2M, etc), nos aparecerán las nuevas columnas en los resultados:

Espero que os sea de utilidad.

Bibliografía:

 

Publicado en Abap, SAP MM | Etiquetado , , , , , , | 5 comentarios

Truco 97. Monitor de pedidos de venta (VA06)


Tras muchos años de espera (yo llevo casi 20 con Sap y echaba de menos algo así), Sap liberó en 2013 el famoso monitor de pedidos, a través de la transacción VA06 (ver nota 1797205). Esta disponible a partir del EHP5, aplicando los correspondientes niveles de parches.

Básicamente, el monitor nos permite realizar los controles más habituales sobre los pedidos, como:

  • Pedidos de cliente incompletos
  • Bloqueos de entrega
  • Posiciones no confirmadas
  • Pedidos atrasados
  • Pedidos con la entrega pendiente de procesar
  • Pedidos con bloqueos de crédito
  • Control de los pedidos de venta asociados a pedidos de compra o pedidos a terceros

Mucha de esta información ya la podemos obtener desde otras transacciones, pero en la VA06 tenemos toda la información en un único sitio y podemos ver de forma detallada los status del documento, tanto a nivel de cabecera como de posiciones.

Al acceder a la transacción, podremos ver los criterios de selección disponibles, donde en la parte superior podremos indicar el tipo de selección a realizar, incluyendo todos los pedidos, solo los incompletos o realizar un filtrado selectivo por los diferentes estados posibles del pedido.

En la parte inferior disponemos de las diferentes pestañas para realizar el filtrado de los documentos a seleccionar, pudiendo definirlo por:

  • Datos del pedido: numero de documento, fecha de creación, solicitante, clase de documento o tipo de posición.
  • Datos organizativos: organización de ventas, canal, sector, oficina de ventas, grupo de vendedores o centro.
  • Datos del material: código de material o grupo de artículos.
  • Ampliaciones: criterios adicionales de cliente.

Interesante la opción disponible en la parte inferior, llamada “Sel.pedido cliente completo si crit.selección son relativos a posición”. Nos permite seleccionar un documento completo en el que alguna de las posiciones cumplan las condiciones de selección.

Tras ejecutar el informe, visualizaremos dos ventanas ALV, donde podremos ver por un lado las cabeceras de los pedidos, y al seleccionar cada documento en ese ventana, las posiciones del documento en el ALV inferior.

A nivel de cabecera, podremos ver muchísimos datos del documento, con especial interés la información sobre el estado: documento incompleto, bloqueo de entrega, bloqueo de crédito, situación de la verificación de disponibilidad, si el documento está retrasado, status del documento sobre si se ha creado entrega o se ha hecho la salida de mercancía sobre esta, etc. Además Sap utiliza semáforos que nos permiten ver la información con más claridad.

A nivel de posición, podemos ver las cantidades de pedido, fecha de entrega, importe, cantidades confirmadas, estado de confirmación, datos incompletos, entrega o salida de mercancia; numero de entrega y su situacion, etc.

La transacción VA06 también puede ser personalizada a través de la BADI  SD_OSO_MONITOR, pudiendo alterar tanto los criterios de selección como los resultados del informe. 

En la nota 2650306 del OSS se explica como realizar esta personalización, incluyendo un documento con un ejemplo de como hacerlo.

Como material complementario, os dejo un vídeo de un tema relacionado con la VA06, que trata sobre la gestión de los pedidos atrasados y como gestionarlos con la transacción V_V2. 

Estas y otros funcionalidades se explican en el curso SAP SD que imparten en saplearn.es y que comienza el próximo 14 de enero de 2018 (3ª Edición). Este año, como novedad, se incluye una sesión donde se explican las diferencias con el nuevo S4/Hana, con sesión práctica incluida. Todavía hay plazas disponibles.

Bibliografia:

https://kb.umbra.com/display/GCSK/BPD-SD-VA06+SAP+Sales+Order+Monitor

Publicado en Formacion, Sap SD | Etiquetado , , , , | 1 Comentario

Truco 96. Identificadores fiscales en Sap.


Como sabéis, cada país tiene sus propios números fiscales que sirven para identificar a los contribuyentes (empresas, organismos, administraciones públicas, personas físicas, etc). Normalmente es un código de diferente longitud que según el estado tiene una estructura diferente, dígitos de control, etc.

Por ejemplo, en España el identificador fiscal se llama NIF o CIF, con el siguiente formato:

NIF/NIE formato: [C1 C2 C3 C4 C5 C6 C7 C8 C9] Donde C1 a C9 son digitos.
Valores:  C1

C2 C3 C4 C5 C6 C7 C8

C9

 Alfabético o numérico.

Numérico.

Alfabético.

 Reglas:  C1 Dependiendo del tipo de entidad:A Sociedad Anónima

B Sociedad de Responsabilidad Limitada

C Sociedades Colectivas

D Sociedades Comanditarias

E Comunidades de Bienes

F Sociedades Cooperativas

G Asociaciones

H Comunidades de propietarios en régimen de propiedad horizontal

J Sociedades civiles con o sin personalidad jurídica

P Corporaciones Locales)

Q Organismos Autónomos

R Congregaciones e instituciones religiosas

S Órganos de la administración del estado y de las Comunidades Autónomas

U Uniones Temporales de Empresas

V – Otros tipos no definidos en el resto de claves
Para personas físicas:

Este dígito corresponderá con el primer número de su DNI o documento de identidad.

Para extranjeros:

X,L,K,M

 C2 C3 Para empresas y organizamos representa la provincia.

Son números aleatorios para las personas físicas.

 C4 C5 C6 C7 C8  Numeros aleatorios
 C9  Digito de control.
 Ejemplo: A58295296 1er digito: Tipo entidad  – “A” Sociedad Anónima –2º y 3er Digito:  Ciudad – “58” Barcelona

4th to 8th digit: Sequential number “29529”

9º digito: Digito control “6

 Detalles NIF/NIE: Para personas jurídicas: https://www.boe.es/diario_boe/txt.php?id=BOE-A-2008-3580

Para personas físicas: https://www.boe.es/buscar/act.php?id=BOE-A-2005-21163

Sap implementa los algoritmos de chequeo de los identificadores fiscales para que los números introducidos en los clientes o en los proveedores sean correctos respecto a la legislación de cada país.

En la parametrización de chequeo por país, en la ruta de custo Sap Netweaver –> Parametrizaciones Generales –> Configurar países –> Configurar verificaciones específicas de país (o a través de la transacción OY17), podemos ver las reglas de verificación de los identificadores fiscales(en lo referente a longitudes).

En este mismo punto de parametrización podemos ver otros chequeos como los referentes a códigos postales, cuentas de bancos, etc.

Truco96_img1

Además de esta parametrización, Sap implementa la programación en el  correspondiente módulo de función donde está programada la verificación según la legislación de cada país.

Para poder localizar esta programación, existe una vista, llamada V_TFKTAXNUMTYPE (transacción SM30), donde podemos ver los diferentes identificadores fiscales de cada país y la rutina utilizada para realizar la verificación (modulo de función).

Truco96_img4

Por ejemplo, para el NIF de España se utiliza el Módulo de función BUPA_TAX_NUMBER_CHECK, que a su vez llama al MF TAX_NUMBER_CHECK. La programación se encuentra en el grupo de funciones TSRV (podemos verlos con la transacción SE80).

Truco96_img2

En el módulo de función TAX_NUMBER_CHECK se realizan las comprobaciones generales de longitudes del identificador según la parametrización de la OY17. Y a continuación realiza la comprobación según el algoritmo específico del país del interlocutor.

Por ejemplo, para España, la verificación se realiza dentro de dicho módulo de función, con las rutinas form:

  • check_taxcode_es
  • check_taxcode_companies
  • check_taxcode_foreigners
  • check_taxcode_persons

Para la verificación del llamada NIF Comunitario (para la comunidad europea), se utiliza el MF VAT_REGISTRATION_NUMBER_CHECK, que a su vez utiliza el MF EU_TAX_NUMBER_CHECK.

Cuando hay algún cambio legal, Sap libera las correspondientes notas que modifican la lógica de las comprobaciones para adaptar a la legislación actual de cada país.

En la página Wiki de Sap existe una documentación completa de los países soportados por Sap y los diferentes identificadores fiscales existentes en cada país, con sus formatos y chequeos (incluidos en el componente CRM-BF-TAX, válido no solo para CRM, sino también para los módulos FI o SD del ERP).

Otro contenido relacionado:

Wiki Country Tax Category Check

Taxes Wiki Page

SAP Note 1691176 : Validation of VAT / tax identification number (EC countries)

 

Publicado en Formacion, Sap CRM, Sap FI | Etiquetado , , | 1 Comentario

Truco 95.Creación/actualización masiva en el maestro de materiales.


Desde siempre nos hemos quejado lo compleja que es la actualización del maestro de materiales y las pocas herramientas que proporcionaba Sap (en el producto ERP)  para gestionar la creación, mantenimiento o ampliación de los datos del maestro de materiales.

Esto es evidente cuando estamos en instalaciones complejas, con muchos centros, sociedades, etc. La carencia en parte se cubría con alguna de las transacciones clásicas:

  • Actualización masiva del maestro de materiales: a través de la transacción MM17 Sap nos permite realizar modificaciones masivas en los materiales existentes, siempre respetando las validaciones que se hacen si esos mismos cambios los realizáramos en las transacciones clásicas (MM02). Esta transacción esta básicamente pensada para realizar modificaciones en masa, aunque también permite, con restricciones, ampliar un material.

Truco95_img1

  • Ampliación de vistas de almacén: con las transacciones MMSC y MMSC_MASS podemos realizar una ampliación de la vista de almacén del material (centro/almacén). Muy útil cuando tenemos varios almacenes en un centro y queremos extender el material a todos los almacenes.

Truco95_img2

  • Ampliación de vistas del material: a través de la transacción MM50 se pueden ampliar las vistas de un material. Por ejemplo, es muy útil para ampliar las vistas de ventas de un material para todas las áreas de ventas o para los centros existentes. Nos permite indicar un material y unidad organizativa modelo para el proceso. El proceso en si no es masivo, ya que equivale a una actualización manual, donde vamos pasando por las diferentes pantallas de las nuevas vistas.

Truco95_img3

 

Os dejo un link de  en los blogs de Sap donde se explica en detalle el funcionamiento de esta transacción MM50:

https://blogs.sap.com/2013/08/03/how-to-extend-material-views-by-using-mm50/

Por suerte, a través de la nota 1880324 Sap liberó a finales de 2013 la transacción MMCC, que permite la creación y ampliación de forma masiva del maestro de materiales. La disponibilidad de esta transacción ha facilitado la vida a los usuarios que gestionan el maestro de materiales.

Truco95_img4

La transacción permite realizar las siguientes funciones:

  • Creación de masiva de un numero determinado de materiales tomando como modelo un material existente, seleccionando las unidades organizativas a utilizar como origen y destino.
  • Ampliar un material ya existente en otras unidades organizativas.
  • Modificar las vistas de un material existente.

Las tablas que se pueden actualizar con la transacción son las siguientes:

  • MARA, MARM, MEAN, MAKT, STXH (datos básicos)
  • MARC, MPOP, MLAN, STXH (datos de centro)
  • MARD (datos de almacén)
  • MVKE, MLAN, STXH (datos de ventas)
  • MLGN, MLGT (datos de WM)
  • MBEW (datos de valoración, vista de contabilidad)

Os recomiendo leer la nota 1880324 donde se explica en detalle todas las posibilidades de la transacción y la forma de operar según el tipo de operación que deseemos realizar.

Por ejemplo, tenemos un material en nuestro sistema (creado en un centro) que queremos ampliar al resto de centros existentes. Indicamos en la pantalla inicial el material modelo, las tablas a ser creadas (datos de centro, datos de almacén, datos de ventas y datos de valoración) y el tipo de ejecución. Podemos filtrar las unidades organizativas que se leerán del material modelo para la propuesta de copia/creación con los filtros.

Truco95_img5

A continuación, indicamos el material que queremos ampliar

Truco95_img6

A continuación indicaremos en cada una de las pestañas las diferentes unidades organizativas a crear y la queremos utilizar como modelo.

Truco95_img7

Finalmente ejecutaremos y se mostrará un log de las acciones realizadas. Si hay algún problema se mostrará en este momento.

Truco95_img8

Como resultado, tenemos a nuestro material 259 creado en todos los centros y organizaciones de ventas indicadas.

Truco95_img11

Como otro ejemplo, la creación de un material que queremos que sea exactamente igual que un material ya creado. Indicamos en la pantalla inicial que queremos crear todas las tablas del nuevo material, material modelo y selección de las unidades organizativas del modelo.

Truco95_img12

En la pantalla de materiales dejaremos el código de material en blanco para indicar que vamos a crear 1 o n materiales nuevos (si tuviéramos numeración externa indicaríamos el nuevo número de material según la codificación utilizada):

Truco95_img13

Revisamos las pestañas de los diferentes datos (estarán las unidades organizativas filtradas del material modelo y el código de la unidad organizativa destino, que podremos modificar).

Truco95_img14

Finalmente ejecutamos y se realizará la creación de los nuevos materiales, en las unidades organizativas indicadas tomando como modelo el material introducido.

Truco95_img15

Como algunas de las restricciones conocidas, podemos indicar que no se copiaran ni crearan los siguientes datos del maestro:

  • Vista de clasificación. Podremos utilizar de forma alternativa la transacción CLMM.
  • Gestión documental (DMS).
  • Información de configurables.
  • Datos de areas de MRP.
  • Datos de calidad.
  • Información complementaria de los materiales: condiciones de precio, listas de materiales, versiones de productos, etc.

Ademas, otras recomendaciones que indica SAP:

  • No cambiar el material modelo durante el proceso de copia.
  • El tipo de material de los materiales a crear se transfiere del material de referencia o modelo y no se puede cambiar.
  • No permite una selección de las vistas a crear (como en la MM50), sino que trabaja a nivel de tablas.

Adicionalmente, la transacción dispone de una transacción de parametrización (MMCU), donde pueden fijar valores por defecto a los usuarios, que pueden ser seleccionados en la ejecución de la transacción MMCC si se desea.

Truco95_img9

Igualmente, existe una BADI, llamada BADI_MATERIAL_CC, que nos permite intervenir en el proceso de creación o ampliación de los materiales con nuestros propios criterios (la creación se realiza via IDOC y podemos modificar su contenido antes del lanzamiento de la creación).

Truco95_img10

Espero que os sea de utilidad este contenido.

Publicado en Formacion, SAP MM | Etiquetado , , , , , , , , | 1 Comentario

Truco 94. Activación automáticas de nuevas rutinas VOFM en la orden de transporte


La transacción VOFM nos permite definir las rutinas que utilizamos en diferentes lugares del sistema, como rutinas condicionales en los esquemas de procesamiento de mensajes, rutinas para el control de copia en los documentos comerciales (pedidos, entregas, facturas), rutinas para utilizar en el esquema de calculo (formulas, condiciones, etc).

Por ejemplo, podemos ver en la imagen siguiente unas rutinas de transferencia de datos para la facturación, que utilizaremos en la configuración del control de copia (transacción VTFL para la facturación desde la entrega o VTFA desde el pedido).

Con estas rutinas podemos personalizar el comportamiento del sistema en los diferentes puntos susceptibles de su utilización.

Cuando creamos nuevas rutinas, hemos siempre de acordarnos, al transportar los objetos del sistema de calidad o productivo, de ejecutar el report RV80HGEN, que realiza la generación del código abap correspondiente y la activación de los objetos. Si no realizamos este paso, no funcionará correctamente en el sistema destino la configuración realizada.

En este post os voy a contar un pequeño truco para obviar la ejecución manual de este report. Lo que haremos será, en la misma orden de transporte donde hayamos incluido los objetos de workbench o desarrollo, incluir una entrada para la ejecución automática del programa RV80HGEN en el momento de importar la orden en el sistema destino.

Para ello, una vez localizada la orden, accederemos a la transacción SE09, seleccionaremos la orden y pulsaremos el botón modificar.

Incluiremos la entrada:

  • ID Programa: R3TR
  • Tipo Objeto: XPRA
  • Nombre objeto: RV80HGEN

Cuando realicemos la importación de la orden, veremos que tarda un poco más de lo normal, apareciendo el mensaje “Execution of reports after import”. En ese momento se realizará la ejecución del report RV80HGEN y automatizaremos el proceso de transporte, sin necesidad de ejecutar posteriormente el report manualmente.

En el log de importación de la orden podremos ver el log de ejecución del programa y localizar cualquier problema que pudiera ocurrir.

¡¡¡Buen fin de semana!!!

Publicado en Abap, Formacion, Sap Basis, SAP MM, Sap SD | Etiquetado , , | 4 comentarios

Truco 93. Abrir una transacción de Customizing en un sistema productivo.


En ocasiones, necesitamos abrir una transacción de parametrización en el sistema productivo para poder realizar cambios directamente en este sistema. Se podría realizar de una forma temporal utilizando la transacción SCC4 para mantener las propiedades de los mandantes, pero es totalmente desaconsejable abrir un mandante productivo de forma permanente o permitirlo directamente a los usuarios finales.

Truco93_0

Es importante remarcar que solo tiene sentido hacerlo en transacciones cuyos valores ha de mantener directamente el usuario o en aquellas que pudieran ir relacionadas con datos maestros para los que es difícil mantener los mismos valores en un sistema de desarrollo o productivo (por ejemplo en la definición de áreas de Planificación para subcontratistas, transacción OMIZ, donde se indica un proveedor que es difícil que podamos definir igual en todos los sistemas por la definición de los rangos de números). Y habrá llevar cuidado con sobrescribir los valores configurados en productivo con transportes realizados desde el sistema de desarrollo.

Algunos de los ejemplos de transacciones que podemos tener abiertas en productivo:

  • OB52: periodos contables abiertos en finanzas.
  • OB58: estructuras de balance, donde se indicas las cuentas contables asociadas.
  • OB08: tipos de cambio.
  • OMIZ: areas de planificación (definición de subcontratistas).
  • OMT3E: parámetros de usuario personalización maestro materiales.
  • 0VTC: definición de rutas de transporte.
  • Parametros para pedidos de traslado (cliente asociado al centro o almacen): vista V_001W_IV o cluster vista MB_DELIV (transacción SM34).

Truco93_1

Según se describe de forma general en la nota 135028 de Sap, la operativa para abrir una transacción de Custo en un sistema productivo sería la siguiente (versión >= 4.6):

  • Buscamos en el árbol de parametrización (transacción SPRO), la opción de custo que queremos abrir. Una vez localizada, pulsamos en ella con el botón derecho del ratón y seleccionamos la opción “Visualizar información técnica”.

Truco93_2

  • A continuación seleccionamos la pestaña “Obj.actualiz.“. La lista de objetos de parametrización estará en la parte inferior de la pantalla, donde pone Objetos asignados.

Truco93_3

  • Haciendo doble clic en el objeto (V_001W_IV en la imagen), podemos hacer que la parametrización se puede realizar directamente en productivo marcando el flag “Parámetros actuales”. Esta configuración la realizaremos en el sistema de desarrollo y la transportaremos a productivo para hacerla efectiva.

Truco93_4

De forma alternativa, una vez conocidos los objetos de parametrización, se pueden modificar igualmente el valor indicado accediendo a la transacción SOBJ.

Truco93_5

En el caso de que nos interese añadir la transacción (si el punto de custo dispone de ella) en los menús de usuario, podríamos hacerlo mediante los roles de autorizaciones (transacción PFCG) o en los menús estándar haciendo una ampliación del menú a través de la transacción SE43 o SE43N, tal y como explicamos en una entrada anterior del blog (ver link).

Nota: es posible que para algunas parametrizaciones Sap no permita la configuración descrita en este post.

Bibliografia:

Existen multitud de notas relacionadas con este tópico, algunas de las más interesantes son:

SAP Note 388936 – OMD0, OMIQ: maintenance not possible, message TK430

SAP Note 317650 – Transporting MRP areas between systems

SAP Note 356483 – Customizing: Current settings in the test system

SAP Note 135028 – Transfer IMG activity to current setting

SAP Note 77430 – Customizing: Current settings

SAP Note 133079 – MD25/MD26: Planning calendar as master data

SAP Note 557503 – OB58: Current settings in test system

SAP Note 538451 – Current settings in non-production systems

SAP Note 522215 – Current settings in non-production systems

SAP Note 512698 – Customizing of DIP profiles in the production system

SAP Note 40672 – System changeability and client control

SAP Note 149752 – Route definition not maintainable in produc. system

Gracias igualmente a Caetano Almeida su entrada sobre el tema en los blogs de Sap.

Feliz 2018 a todos.

happy-new-year-images-2018-hd-4-1

Publicado en Formacion, Sap Basis | Etiquetado , , , , , | 2 comentarios

Truco 92. Añadir documentos en el Content Server (Archivelink) a partir de mensajes.


Hace algún tiempo hablamos, en una serie de posts, de la gestión documental básica y como podíamos gestionarla en Sap. Os dejos los links a los 3 posts relacionados:

En concreto, hablamos del Archivelink y de como anexar, a los objetos de negocio, ficheros del tipo word (.doc), excel (.xls), pdf, jpg, etc.

Mensajes1

Los documentos anexados luego podían ser consultados desde los mismos documentos con la opción Lista anexos en el GOS o a través de la transacción OAAD.

Mensajes2

Revisar el correspondiente post donde explicamos toda la funcionalidad asociada y la forma de realizar la configuración de esta.

Nota: en el módulo de ventas es necesario poner el parámetro de usuario SD_SWU_ACTIVE con el valor X para activar el GOS en la transaccion VA02/VA03.

Hay una funcionalidad no demasiado conocida que nos permite, de forma totalmente estándar, generar anexos en el archivelink al procesar los mensajes asociados a los documentos.

Por ejemplo, si queremos que cada vez que se emita una factura de ventas, el sistema automáticamente guarde en la gestión documental dicho documento en formato PDF, lo podríamos realizar de una forma muy sencilla. Es requisito para poder utilizar esta funcionalidad tener un gestor documental instalado (se recomiendo nunca almacenar los documentos en la misma base de datos donde se encuentra SAP) y realizar la parametrización del Archivelink.

Para entender como configuraríamos el sistema, vamos a ver un ejemplo práctico utilizando las facturas de ventas.

Configuración de las clases de mensaje.

En la transacción NACE, seleccionaremos la aplicación V3 Facturacion y la opción Clases de Mensaje. Por ejemplo, para el mensaje estándar de la factura (RD00), podremos configurar en la pestaña “Sistema Archivo” la forma de realizar el archivado y que Clase de documento de los configurados en el Archivelink utilizaremos para almacenar el mensaje en la gestión documental cuando este sea procesado.

Mensajes3

En nuestro ejemplo,  hemos indicado la clase de documento ZPDF, que previamente hemos configurado utilizando la transacción OAC2. Esa clase de documento es un documento lógico al que se asigna un tipo de documento (tipo de formato). Previamente habremos configurado los repositorios de contenido (transacción OAC0) donde se almacenarán los documentos, y asignado este a la clase de documento ZPDF y el objeto de negocio, VBRK en este caso (transacción OAC3).

Mensajes4

Registros de condición de los mensajes.

Al crear los registros de condición para la generación automática de los mensajes (transacción NACR, aplicación V3, clase de mensaje RD00 en mi caso; o transacción VV31/VV32), indicaremos como queremos que sea su tratamiento en los relativo a su inclusión en la gestión documental.

Mensajes5

Si indicamos el valor 1 Solo imprimir, solo se realizará su tratamiento convencional (impresión, por ejemplo) y no se generará el documento en el archivelink.

Con los valores 2 Solo archivar o 3 Imprimir y archivar si se generará el correspondiente documento anexado.

Tratamiento de los mensajes.

Cuando se procesen los mensajes (bien de forma automática al grabar los documentos) o bien al tratarlos de forma manual por parte del usuario (transacción VF31 para el caso concreto de las facturas de ventas), el sistema realizará la generación del anexo en el formato correspondiente y lo vinculará al documento tratado, siendo guardado en el gestor documental.

Mensajes6

Tras procesar el mensaje, si consultamos la factura desde la VF02, pulsando el botón Servicios para objeto (GOS), opción Lista anexos, podremos ver que se ha generado un anexo en la gestión documental del archivelink asociado a la factura para la que procesamos el mensaje.

Mensajes7

Igualmente, desde la transacción OAAD con la opción “Búsqueda técnica” en la sección Documentos podremos realizar la búsqueda de los documentos anexados a la factura podremos realizar la búsqueda o consulta de los anexos.

Mensajes8

Si accedemos al anexo, podremos ver que tenemos nuestro formulario de factura perfectamente almacenado en formato PDF y vinculado a la factura original que fue el origen del mensaje.

Mensajes9

Todo de una forma estándar y sin necesidad de programación. En una próxima entrada del blog veremos que también se pueden generar de manera similar Listas de spool (listados)en la gestión documental.

Publicado en Formacion, Sap Basis | Etiquetado , | 3 comentarios

Truco 91. Análisis de modificaciones del precio medio variable de un material.


Cuantas veces nos hemos encontrado con el típico problema de tener un precio medio variable en la valoración de un material (vista de contabilidad) y no ser capaces de entender cual es el motivo u origen de ese valor.

MBEW1

Normalmente, intentamos buscar una explicación mirando algunas de estas cosas:

  • Tablas de la base de datos: en la tabla MBEW tenemos la información actual de la vista de contabilidad, donde podemos ver el precio medio variable. En la tabla MBEWH tenemos el histórico de precios para periodos anteriores (siempre que haya movimientos habrá registro para un mes). Puede ser una primera aproximación para analizar de forma general cambios de precio muy significativos.

MBEW2

  • Analizar los documentos de material: podemos intentar sacar las modificaciones de precio utilizando la MB51 (listado de documentos de material), pero habrá operaciones que no tendrán reflejo ahí, como el registro de facturas o modificaciones de precio con la MR21 o MR22.
  • Utilizar el calculo de stock a una fecha: con la transacción MB5B podemos hacer un análisis de los movimientos realizados para un material durante un periodo, incluyendo operaciones que no son movimientos de stock pero que si afectan a la valoración del material.

MBEW3

  • Documentos contables por material: con la transacción MR51 podemos listar esta información, que es posible nos ayude a encontrar el motivo del cambio del precio. Esta herramienta no distingue entre contabilizaciones hechas con stock libre o stocks especiales (E, Q), y en ocasiones no se puede utilizar correctamente (ver  KBA 1506200).

Es posible que en este momento ya hayamos encontrado una explicación al precio que presenta nuestro material.

Con el objetivo de ayudarnos en nuestro propósito Sap libero, a través de la nota 2198317, el report MBMAPCHANGES. Este programa pretende ser la herramienta para que los usuarios puedan analizar los cambios de precios sin necesidad de combinar varias transacciones, contenidos de tablas, etc.

Algunas de las características del report:

  • Informe en formato ALV, que muestra todos los documentos que han cambiado las cantidades de stock o su valor.

MBEW4

  • Distingue entre los diferentes tipos de stock: libre utilización, stock especial pedido (E) o de proyecto (Q), que tienen sus propias valoraciones.
  • Incluye navegación a los documentos de referencia.
  • Remarca los documentos que tienen cambios significativos en el precio (en mi ejemplo, realice un cambio de precio muy grande con la MR21 y esa linea aparece remarcada en rojo). Si navego al documento puedo ver como me lleva a la transacción CKMPCD, donde consulto del documento de cambio de precio).

MBEW6

  • Incluye documentación sobre la forma de calculo y los escenarios incluidos en la herramienta.

MBEW5

Nota: el informe se crea al aplicar la nota 2198317, que incluye pasos manuales para su implementación. La nota 2256487 es necesario aplicarla igualmente.

Seguramente con este informe nos hubiéramos ahorrado unas cuentas horas de búsqueda para entender un precio. Entendemos la complejidad de Sap, pero alguna herramienta como esta más a menudo no estaría mal para facilitar la vida al usuario.

Publicado en Formacion, SAP MM | Etiquetado , , , , , , , , , , | 4 comentarios