Empezando con S/4HANA. Business Partner (BP).


En las entradas publicadas en el blog normalmente hablamos de funcionalidad de la versión ECC del ERP de SAP (6.0 EHPX, antes llamado R3). Hace unos meses hablamos de los cambios más relevantes que nos podemos encontrar en el nuevo sistema S/4HANA y la forma de acceder a un sistema Cloud gratuito de demostración que ofrece SAP (ver post aquí).

image-1

Hoy vamos a dar un salto adelante y vamos a empezar a descubrir en detalle los cambios que nos encontraremos cuando decidamos migrar nuestro sistema al nuevo S/4HANA o cuando nos encontremos en un proyecto de implantación con la nueva versión.

En concreto, vamos a hablar de unos de los cambios más importantes y que más afecta a la parte de Gestión de Materiales (MM) o Ventas (SD), los Business Partners.

Antes de entrar en materia, os recomiendo leer y conocer las llamadas Simplification Lists. Es un documento donde Sap nos detalla toda la funcionalidad liberada en cada versión de S/4HANA. Allí se enumeran desde las transacciones que desaparecen en la nueva versión, cambios en los modelos de datos, nueva funcionalidad liberada o cambios respecto a las versiones anteriores, detalle de notas asociadas a cada punto, etc. La relacionada con la versión 1909 tiene más de 1000 páginas, todo un reto para entender todas las implicaciones a las que nos vamos a tener que enfrentar en un proyecto de migración o una nueva implantación.

Business Partner Approach

En las versiones anteriores manteníamos los datos de nuestros clientes o proveedores en diferentes transacciones (FKXX/MKXX/XKXX para proveedores o FDXX/VDXX/XDXX para clientes), cada una con sus respectivas tablas según el ámbito organizativo de los datos (LFA1/LFB1/LFM1 para proveedores, entre otras o KNA1/KNB1/KNVV para clientes). Ademas de otros objetos de negocio como podían ser unidades organizativas, personas, etc.

En S/4HANA se sustituye este enfoque y pasamos al objeto BUSINESS PARTNER como elemento centralizado donde se realizará toda la gestión de datos maestros asociados a los clientes y proveedores.

BP_013

Con el nuevo enfoque tenemos un único elemento organizativo (el Business Partner), al cual le podemos asignar diferentes roles según la relación que tengamos con el en nuestra organización. Por ejemplo, un empresa con la que trabajemos estará creada una única vez, pero podrá desempeñar el rol de cliente, de proveedor, etc. Esto nos permite trabajar con datos compartidos y unificados (datos de direcciones, contacto, datos bancarios), así como datos específicos asignados a cada rol (cliente en finanzas, cliente en ventas, proveedor en finanzas, proveedor en compras).

BP_004

Ademas, con la utilización de este elemento central se solucionan limitaciones que teníamos en el antiguo ERP como:

  • Definición de varias direcciones, cada una de ellas con un uso concreto.
  • Validez temporal de los elementos (direcciones, datos bancarios).

BP_001

  • Ampliación de la información disponible en los datos maestros (por ejemplo, identificadores fiscales según el país).
  • Definición de múltiples relaciones con el mismo BP.
  • Máximo grado de compartición de datos maestros y su reutilización.

En S/4HANA, las transacciones clásicas desaparecen y cuando las utilicemos, el sistema nos redireccionará a la transacción BP.

Usando el mismo BP, y asignándole los correspondiente roles, podremos tener un cliente para Finanzas (rol FLCU00 FI Customer) o para utilizar en el módulo de SD (rol FLCU01 Customer para ventas).

BP_002

O un proveedor (roles FLVN00 FI Vendor para ser utilizando en Finanzas y el rol FLVN01 Vendor para los datos de compras).

Funcionalidad.

A nivel funcional, la nueva transacción BP es bastante diferente a las clásicas que utilizabamos en la versión anterior. Cuando vayamos a crear un nuevo interlocutor (cliente o proveedor), lo primero que hacemos es crearlo de forma general, indicando que vamos a crear una organización y el BP role “000000 Business Partner (Gen)”. 

BP_007

Es algo parecido a la creación de datos generales (a nivel de mandante) para un cliente o proveedor (direcciones, identificación fiscal, cuentas bancarias, etc).

Importante: en el campo Grouping indicaremos el valor que determinará la numeración del objeto (internamente también determinará el grupo de cuentas que se utilizará para la creación del interlocutor).

A continuación, una vez grabados los datos y asignada la numeración, podremos pasar a la ampliación del interlocutor con los diferentes roles. Entraremos en la transacción de nuevo en modo Update e indicaremos el nuevo rol que vamos a crear. Por ejemplo, con el rol FLCU00 FI Customer, crearemos los datos de Finanzas.

BP_008

Estos datos los tendremos a nivel de sociedad. Los mismo posteriormente si queremos crear las vistas de venta, con el rol FLCU01 Customer.

BP_009

Los datos requeridos en cada una de las secciones pueden variar según el BP role seleccionado. De esta forma, habremos creado el cliente y lo tendremos listo para utilizar tanto en finanzas (FI) como en ventas (SD).

Implicaciones técnicas.

La primera sorpresa, aparte de los cambios en la funcionalidad más que evidentes, es a nivel técnico. Resulta que el uso de los BP no implica la desaparición de los antiguas tablas de datos de clientes y proveedores, que se mantienen a nivel técnico por requisitos de compatibilidad y funcionamiento de los diferentes módulos (MM,SD, etc).

Para mantener este funcionamiento y que todo sea totalmente transparente para el usuario, Sap ha desarrollado lo que llama el Customer Vendor Interface (CVI), que permite, de forma automática, mantener la información en las tablas clásicas a partir de la información introducida en los Business Partner. Toda una sorpresa.

BP_012

Esto significa que, al dar de alta o modificar los datos existentes en un BP, automáticamente se actualizaran las correspondientes tablas de proveedores o clientes preexistentes.

A nivel de tablas, tendremos la información de los Business Parters en tablas BUTXX, pero seguiremos teniendo nuestras queridas KNA1, KNB1, KNVV o LFA1, LFB1 o LFM1.

BP_005

El CVI requiere una parametrización para definir las equivalencias entre los BP Grouping (es el elemento que nos permite realizar la numeración de los business partners y que se indica al crearlos), con los grupos de cuentas que utilizábamos en las transacciones clásicas de R3 al crear un cliente o proveedor.

BP_006

Habrá que alinear la numeración del BP definida a traves del Grouping con la numeración asignada en los Grupos de cuentas (esto puede ser un tema bastante complicado en una migración desde un sistema previo con miles de clientes o proveedores ya definidos).

BP_010

En la parametrización de la integración, asignamos al “Grouping” utilizado en el BP, el correspondiente “Account group” (grupo de cuentas), utilizado anteriormente al crear los clientes. Tanto para clientes, como proveedores (ver imagen siguiente).

BP_011

En el apartado de bibliografía os he dejado al documento HANA Cookbook Customer Vendor Integration (CVI), y el BP_Conversion_Activities_Document,  donde se explica en detalle esta integración y la forma de configurarla.

Nota: la misma herramienta CVI nos permite preparar el upgrade a S/4HANA, de forma que cuando creemos un cliente o proveedor de la manera tradicional, el sistema creará automáticamente el BP asociado (para el periodo de transición antes de la migración y como una tarea necesaria dentro de este proceso). Y ya tendremos realizado uno de los pasos a realizar en la migración de forma previa.

Autorizaciones.

Además, tendremos que ajustar todos nuestros roles de autorización para trabajar con los nuevos objetos. Se mantendrán las autorizaciones clásicas para la compatibilidad con el antiguo modelo de datos, pero a su vez tendremos que habilitar acceso a las funciones de la BP con los objetos:

  • B_BUPA_GRP – Authorization Groups: podremos utilizar estar autorización para indicar que Business Parters podran ser editados por el usuario en base al valor del campo “Authorization Group” dentro de los datos maestros. Por ejemplo, a todos los BP que le hayamos puesto el valor “GROUP” (empresas del grupo), solo podran ser matenidos con los usuarios que tenga este objeto con dicho valor.
  • B_BUPA_ATT – Authorization Types: utilizando esta autorización, podemos definir que BP pueden ser mantenidos por el usuario, dependiendo de los valores de determinados campos. En la parametrización definiremos los nombres de los “Authorization types”  y los campos que podrán ser utilizados para el chequeo.
  • B_BUPA_FDG – Field Groups: con esta autorización indicamos que grupos de campos y con que actividades pueden ser gestionados por el usuario (visualizados o modificados).
  • B_BUPA_RLT – BP Roles: con este objeto de autorización vamos a indicar que BP roles podrán ser editados por el usuario.

Como podéis comprobar, el irnos a S/4Hana no va a ser un camino fácil ni es un simple cambio de nombre. Vamos a prepararnos para muchos cambios.

Bibliografía:

BP and CVI in SAP S/4HANA System Conversion.

HANA Cookbook Customer Vendor Integration (CVI): configuración de la integración de BP y clientes/proveedores clásicos utilizando CVI.

2265093 – S4TWL – Business Partner Approach

SAP S/4HANA Business Partner and Customer / Vendor Integration

BP_Conversion_Activities_Document

01_TOP-Item_MD_Business-Partner-Approach_Version5.0

https://blogs.sap.com/2019/08/06/how-to-create-a-bp-business-partner/

https://blogs.sap.com/2019/09/20/intelligent-erp-sap-s4hana-1909-release/

Publicado en Formacion, S/4HANA | Etiquetado , , , | 1 Comentario

Truco 112. Personalización del registro de factura de compras (MIRO)


En nuestro truco de hoy volvemos al módulo de Gestión de Materiales (MM), y vamos a hablar de la transacción MIRO. Como sabéis, esta transacción es la función principal para el registro de facturas de proveedores, en escenarios en los que utilizamos los pedidos para gestionar nuestro procesos de aprovisionamiento.

Cuando no hay pedido, se podría registrar directamente la factura en Finanzas, utilizando la transacción FB60.

La transacción MIRO es una transacción Enjoy que tiene integradas en una única pantalla toda la funcionalidad necesaria para poder registrar nuestras facturas contra pedido.

Truco112_img1

Es una transacción nada sencilla y que suele dar muchos quebraderos de cabeza a los usuarios, por la cantidad de alternativas de funcionamiento que tiene. Además, nos permite gestionar los diferentes tipos de compras que permite el estandar:

  • Compras a stock.
  • Compras imputadas con o sin entrada de mercancía
  • Compras de servicios
  • Gestión de costes indirectos planificados o no planificados en los procesos de compra.
  • Compras provenientes de otros módulos, como gastos de transporte (LE-TR) o de otros sistemas, como SAP Transport Management (TM).
  • Gestión de abonos o cargos/descargos posteriores.

En nuestro post de hoy vamos a hablar de las opciones que nos deja Sap para poder personalizar la transacción y donde podemos “meterle mano”.

Exit disponibles.

Aunque os recomiendo utilizar las BADIs, existen gran cantidad de ampliaciones clásicas (CMOD) para poder personalizar la transacción. Son las siguientes:

  • MM08R001 Liquidación facturación (verificación facturas convencional): nos permite intervenir en el proceso de liquidación de la autofacturacion (Sap lo llama ERS). Podemos modificar el estándar en el proceso de creación de las autofacturas a través de la transacción MIRO.
  • MM08R002 Verificaciones de tolerancia: personalización de la verificación de tolerancias o desviaciones en el momento de grabar las facturas.
  • LMR1M001 Transferencia de los datos de la cabecera del documento y de la posición de documento:  en esta ampliación podemos modificar la propuesta de imputación, añadir campos Z en la cabecera del documento o realizar chequeos en los datos de la factura antes de contabilizar. Esta exit sería la que usaríamos para añadir nuestras propias verificaciones.
  • LMR1M002 Modificación de cuenta para la determinación de cuentas de EM/RF: nos permite modificar los criterios para la determinación de la cuenta de facturas pendientes de recibir. De esta forma, sobre escribimos los valores determinados por la parametrización (OBYC), clase de cuenta WRX.
  • LMR1M003 Asignación de números en la verificación de facturas de Logística: la numeración en la MIRO es un único contador por parametrización. Con esta exit, podemos personalizar la numeración de las facturas (por ejemplo, por sociedad). En un post anterior del blog hablamos de esta exit.
  • LMR1M004 Textos de la posición en documentos subsiguientes: en esta exit podemos modificar el texto de posición que se transferirá al asiento contable en finanzas, cuando contabilicemos la factura.
  • LMR1M005 Modificar criterios para liberación de contabilización de documentos: la exit se llama cuando se realiza la liberación de documentos preliminares.
  • RMVKON00 Facturación de material en consignación/pipeline: nos permite modificar la creación automática de la factura que se produce en los procesos de liquidación de consigna de proveedor o pipeline (transacción MRKO).
  • MRMH0001 Liquidación autofacturación (verificación de facturas en Logística): podemos modificar el estándar en el proceso de creación de las autofacturas a través de la transacción MRRL (por ejemplo, para la fecha de la factura, referencia, etc).
  • MRMH0002 Recepción de factura EDI (verificación de facturas en Logística): tratamiento de los IDOCS de entrada para la creación de facturas. En ellos podemos cambiar la determinación de la sociedad o el proveedor, los indicadores de impuestos, imputaciones o realizar modificaciones en los segmentos de los idocs.
  • MRMN0001 Edición de mensajes: tratamiento de mensajes asociados a la verificación de facturas.

Es muy habitual utilizar estas exits. Yo casi siempre he utilizado la de la personalización de la numeración de las facturas, verificaciones adicionales o aquellas relacionadas con los procesos de autofacturación o liquidación de consigna (donde el estándar tiene muchas limitaciones).

Badis disponibles.

A continuación vamos a hablar de las badis disponibles para el registro de facturas, donde tenemos un abanico más amplio de temas a personalizar (os recomiendo la lectura de la nota 1156325). Algunas de las badis mas interesantes son:

  • INVOICE_UPDATE: esta diseñada para ejecutar chequeos durante la entrada de la factura o la contabilización en la transacción MIRO. Solo se pueden añadir mensajes en el método CHANGE_AT_SAVE  y no se puede realizar ningún cambio en los datos de la factura.
  • MRM_HEADER_CHECK:  podemos utilizarla para realizar chequeos adicionales en la cabecera o en las posiciones de la factura.
  • MRM_HEADER_DEFAULT: nos permite definir valores por defecto al entrar en las transacciones de registro de factura. Por ejemplo, la clase de documento financiero a usar en la contabilización, texto de cabecera, fecha de documento, etc.
  • MRM_MRIS_HDAT_MODIFY: nos permite cambiar algunos campos de cabecera en la contabilización de planes de facturación (ejecución de la transacción MRIS).
  • MRM_MRIS_IDAT_MODIFY: idem que la anterior, pero los cambios son en las posiciones de la factura, al ejecutar la liquidación de planes de facturación.
  • MRM_MRKO_HDAT_MODIFY: en la liquidación de consigna o pipeline, con esta Badi podemos cambiar el vendedor o la clase de documento contable que se utiliza en la contabilización al ejecutar la transacción MRKO.
  • MRM_PAYMENT_TERMS: esta badi se puede utilizar para cambiar las condiciones de pago en la cabecera de la factura (campos que intervienen en el cálculo de la fecha de vencimiento, ZFBDT, ZBD1T, ZBD1P, …, ZLSPR).
  • MRM_RELEASE_CHECK: en esta badi podemos incluir criterios de chequeo adicionales antes de la liberación de facturas bloqueadas para el pago.
  • MRM_TOLERANCE_GROUP: nos permite personalizar los grupos de tolerancia utilizados en la verificación de la factura (normalmente hay un grupo de tolerancia que se asigna en el proveedor, en los datos de sociedad). Esta badi cambiaría el grupo de tolerancia por el que nosotros indiquemos.
  • MRM_TRANSACT_DEFAULT: cuando entramos en la transacción MIRO, el sistema nos ofrece una seria de opciones por defecto (que se quedan guardadas para cada usuario en la tabla ESDUS). Esas opciones corresponden a los valores utilizados en la última ejecución de la transacción. Con la BADI, podemos cambiar los valores propuestos por el sistema, cambiando los valores para los campos “Actividad”, Tipo de documento de referencia, Variante de visualización, o si aparece abierto el Pool de trabajo para documentos preliminares o aparcados o la estructura de pedido (secciones que se pueden abrir y cerrar a la izquierda en la pantalla de la transacción).

Truco112_img2

  • MRM_UDC_DISTRIBUTE: en el estándar, los costes indirectos no planificados que se introducen en la cabecera de la factura, se distribuyen de forma proporcional al importe entre las posiciones de dicha factura. Con esta BADI podemos definir nuestros propios criterios de distribución de los costes. En la imagen podemos ver como hace el estándar el reparto de un coste indirecto (100 Euros en el ejemplo), en base al importe de cada una de las posiciones de la factura. Con la BADI podríamos modificar la forma de hacer este reparto.

Truco112_img3

  • MRM_ITEM_CUSTFIELDS: para gestionar los campos de cliente a nivel de posición en la factura.
  • MRM_ERS_HDAT_MODIFY: utilizada en la liquidación de la autofacturación (transacción MRRL), para cambiar la cabecera de la factura.
  • MRM_ERS_IDAT_MODIFY: utilizada en la liquidación de la autofacturación (transacción MRRL), para cambiar las posiciones de la factura.
  • INVOICE_BW: ejecutada en la transferencia de datos a BW. Nos permite ajustar las estructuras de comunicación para la información que se envía al sistema de reporting.
  • MRM_BLOCKREASON_DELETE_CUST: esta badi se llama en la transacción de desbloqueo de facturas (MRBR) y nos permite establecer criterios para anular los bloqueos de factura.
  • MRM_INVOICE_UPDATE: nos permite establecer chequeos al modificar o borrar facturas en determinadas circunstancias (al planificar una factura para el procesamiento en proceso de fondo, al registrar facturas erróneas mediante entrada EDI o al borrar un documento).

Ejemplo práctico.

En nuestro ejemplo vamos a realizar una mejora en la verificación de facturas doble, utilizando la BADI MRM_HEADER_CHECK. Como sabéis, el estándar tiene una verificación que nos permite controlar que una factura no se contabilice varias veces. La funcionalidad se activa en los datos maestros del proveedor,a nivel de sociedad, marcando el flag “Verif. fra.dob” (verificación de facturas doble).

Truco112_img5

Asociada hay una parametrización, donde se indica, por sociedad, como queremos que se haga esta verificación (transacción OMRDC).

Truco112_img6

Por defecto, el sistema compara los siguientes valores: sociedad, proveedor, referencia, fecha del documento, importe y moneda. Son muchos campos a revisar que pueden determinar que no se encuentra una factura duplicada, cuando realmente si lo es. Si desmarcamos el flag en la parametrización de la imagen, ese criterio no se utiliza para buscar (sociedad, referencia o fecha factura).

Para mejorar la verificación, hemos implementado la badi MRM_HEADER_CHECK para que se compruebe que la factura (buscando por referencia), no se repita el mismo año para el proveedor (en otra fecha) o no se repita en otro año.

method IF_EX_MRM_HEADER_CHECK~HEADERDATA_CHECK.

  DATA wa_rbkp     TYPE rbkp.
  DATA lv_document_nr TYPE rbkpXBLNR.
  DATAlv_duplic(1),
       lv_text(30).

  clear lv_duplic.
  IF sytcode ‘MIRO’.
    IF i_rbkpvxblnr NE space and i_rbkpvlifnr is not initial.
      lv_document_nr i_rbkpvxblnr.

* Miramos que la factura, usando la referencia, ya exista en el mismo año
* con otra fecha. Con la misma fecha ya lo habra buscado el estandar.
        SELECT SINGLE into wa_rbkp FROM  RBKP
                      WHERE  GJAHR  i_rbkpvgjahr
                      AND    XBLNR  lv_document_nr
                      AND    BUDAT  <> i_rbkpvbudat
                      AND    LIFNR  i_rbkpvlifnr.
        IF sysubrc eq 0.
           lv_duplic ‘X’.
           lv_text ‘Existe en el año, otra fecha’.
        else.
* Miramos que exista en otro año.
           SELECT SINGLE into wa_rbkp FROM  RBKP
                      WHERE  GJAHR  <> i_rbkpvgjahr
                      AND    XBLNR  lv_document_nr
                      AND    LIFNR  i_rbkpvlifnr.
           IF sysubrc eq 0.
              lv_duplic ‘X’.
              lv_text ‘Existe en otro año’.
           ENDIF.
        endif.
        if lv_duplic ‘X’.
           message W000(zsistemaswith lv_text
                                     wa_rbkpBELNR
                                     wa_rbkpGJAHR.
        endif.
   endif.
  endif.
endmethod.

En cualquier caso, la verificación es un warning que avisa el usuario de la duplicidad de la factura, mostrándole el documento donde se produce la “colisión” y el motivo:

Truco112_img4

Es un ejemplo rápido de como podríamos establecer este tipo de control al grabar las facturas. Lo tendríamos que mejorar y optimizar con la ayuda de un abaper y realizar un análisis mas en profundidad de las casuísticas a controlar.

Bibliografía.

Campos de cliente en la BAPIs de creación de facturas de compra: https://apps.support.sap.com/sap/support/knowledge/preview/en/2149315

Añadir campos Z en la transacción MIRO: http://wiki.sdn.sap.com/wiki/display/Snippets/Display+customer+fields+in+header+of+logistics+invoice+verification+transactions

Nota 1156325 – BAdIs in the Logistics Invoice Verification environment MIRO

Numeración de facturas en la MIRO personalizada: https://saptricks.wordpress.com/2014/08/16/truco-69-numeracion-de-facturas-personalizada-compras-miro-y-ventas-vf01vf04/

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

Truco 111. Bloqueo de entrega / factura en pedidos. Desactivar la modificación del bloqueo mediante autorizaciones.


En una entrada anterior del blog hablamos del motivo de rechazo en los pedidos de venta y como gestionar las posiciones que no iban a ser servidas a nuestro clientes y sus implicaciones.

En nuestro truco de hoy vamos a hablar de otro tema relacionado con los pedidos de venta, en concreto sobre los bloqueos de Entrega y Facturación.

Truco111_img1

¿Para que valen los bloqueos?.

En los pedidos de venta disponemos de dos tipos de bloqueo de forma estándar (aparte del bloqueo de crédito, del cual hablaremos próximamente en nuestro blog): bloqueo de entrega y bloqueo de factura.

Bloqueo de entrega.

Se puede indicar tanto a nivel de cabecera como a nivel de reparto en las posiciones en el pedido de ventas. También en las entregas se puede indicar a nivel de cabecera. El bloqueo de entrega, dependiendo de su parametrización, nos puede impedir las siguientes cosas:

  • Transferencia de necesidades: impide que se transfiera la necesidad de stock del pedido a la planificación para el documento o posiciones bloqueadas. Es muy útil para restringir que determinados documentos tenga impacto en la planificación y el aprovisionamiento (producción o compras).
  • Creación de las entregas: si se asocia el motivo de bloqueo de entrega a la clase de entrega, el sistema dará un mensaje de error cuando intentemos crear una entrega a partir de un pedido que tenga asignado ese bloqueo.
  • Aparición del documento en los pools de trabajo de las entregas (VL10X). Con esto evitamos que los operarios de almacén tengan estos documentos en sus pools de trabajo.
  • Procesos de picking o de contabilización de mercancía: si el bloqueo está en la entrega, se impedirá realizar estas actividades.

Truco111_img16

  • Generación de mensajes en la entrega: para evitar que se impriman formularios o se generen mensajes automáticos (tipo EDI o integraciones con otros sistemas, por ejemplo) (si el bloqueo esta en la entrega).

El bloqueo se pueden predeterminar a nivel de cliente, de forma que cualquier documento que creemos para un solicitante heredará el bloqueo de entrega indicado a nivel general o a nivel de área de ventas (transacciones XD01/XD02 o VD01/VD02).

Truco111_img2

Esto es útil para determinados clientes problemáticos para los que queremos evitar operaciones (problemas de pagos, verificación de documentación, aspectos legales). Ojo, la transferencia del bloqueo del cliente al pedido solo se realizará si se configura adecuadamente el motivo de bloqueo.

También podremos configurar los documentos de venta (transacción VOV8) para que se inicialicen por defecto con un motivo de bloqueo de entrega o de factura al crear un nuevo documento.

Truco111_img4

De esta forma, nos aseguramos que determinadas clases de documento ya nazcan por defecto bloqueados (por ejemplo, las solicitudes de cargo o abono, las devoluciones, que suelen ser documentos que han de ser autorizados por un responsable).

Bloqueo de factura.

Se puede indicar a nivel de cabecera y a nivel de posición en el pedido (también a nivel de cabecera y posición en la entrega). Este bloqueo impide realizar los procesos de facturación. Cuando intentemos realizar la factura de un pedido con bloqueo de factura, la creación de la factura no será posible y se mostrará un mensaje similar a este:

Truco111_img5

Como hemos indicado antes, se puede predefinir en el customizing que un pedido ya nazca con el bloqueo de factura por defecto. Resulta una forma muy sencilla de evitar que se facturen documentos por error que requieren una verificación adicional. También se puede indicar un bloqueo automático de factura por tipo de posición en la parametrización.

Indicando un bloqueo de factura en el cliente (datos de bloqueo), también podremos impedir que se creen las facturas de determinadas clases (ver sección de parametrización más abajo), si al cliente se le ha asignado uno en sus datos maestros.

Listado de documentos bloqueados.

Existen varios transacciones para consultar los documentos bloqueados. 

  • VA14L: listado de documentos bloqueados para entrega. Nos permite visualizar el origen del bloqueo (cabecera, reparto de una posición, status de usuario o control de crédito).

Truco111_img6

  • V23: documentos bloqueados para la facturación. Con un formato similar al informe anterior, podremos ver si el bloqueo esta a nivel de cabecera o posición, o viene determinado por el control de crédito o los status de usuario en el documento.

Parametrización de los bloqueos.

La parametrización de los bloqueos de entrega se realiza en la ruta de parametrización Logistic Execution –> Expedición –> Entregas –> Definir motivos de bloqueo en la expedición. La parametrización consta de dos partes:

  • Definición de los motivos de bloqueo: en la opción “Entregas: Motivos/Alcance de bloqueo” creamos los motivos y como es la repercusión en un documento que tenga este bloqueo.

Truco111_img3

El significado de cada uno de los flags es el siguiente:

    • Bloqueo Pedido: si se marca, y un cliente tiene este motivo, será transferido automáticamente al pedido y se emitirá un aviso al crear o modificar el pedido.
    • Bloqueo necesidades: impide que se transfieran necesidades a la planificación para el pedido con este bloqueo.
    • Bloqueo Pool entregas: impide que un pedido con este bloqueo aparezca en el pool de entregas (se filtran de forma automática los motivos de bloqueo que tenga marcado este flag).

Truco111_img10

    • Boqueo impresión: impide que se generen los mensajes para entregas con este bloqueo.
    • Bloqueo Picking: si una entrega tiene este motivo asignado (recordemos que el motivo de bloqueo de entrega se transfiere desde el pedido al crear la entrega), no se permitirá realizar el picking.
    • Bloqueo Salida mercancías: ídem que en el punto 5, pero para contabilizar la salida de mercancía de la entrega.
  • Repercusión del bloqueo según clase de entrega: en la opción ” Entregas: Bloquear” realizamos una asociación clase de entrega y motivo de bloqueo de entrega. Esto determinará que será imposible crear una entrega de la clase XX a partir de un documento de venta que tenga asignado los motivos de bloqueo indicados.

Truco111_img7

Para los bloqueos de factura, utilizaremos la ruta Comercial –> Facturación –> Documentos de facturación –> Definir motivos de bloqueo para la facturación. La parametrización consta igualmente de dos partes.

  • Definición de los códigos de bloqueo: en la opción “Factura: Motivos de bloqueo” tenemos una parametrización sencilla donde solamente se definen los códigos de bloqueo y su descripción. Los bloqueos asignados a los documentos (tanto pedidos como entregas), serán automáticamente efectivos de cara a impedir la creación de la factura.

Truco111_img8

  • Bloqueos por clase de factura: en la opción “Asignar clases de factura a motivos de bloqueo”. Con esta parametrización conseguimos que si el cliente tiene asignado el motivo de bloqueo para factura XX y va a crear una factura del YYYY, y este factura del tipo YYYY esta asignado en el custo al motivo de bloqueo, el sistema impedirá la creación de la factura. Con esta parametrización conseguimos que se impida facturar determinadas clases de facturas a un cliente que este bloqueado (aunque los documentos no estén bloqueados).

Truco111_img9

Control de modificaciones de los bloqueos por autorizaciones.

Hemos visto como funcionan los bloqueos, pero ¿que ocurre si cualquier usuario que tiene acceso a la transacción VA02 puede realizar la modificación del pedido y quitar o poner estos bloqueos?. En ese caso perdemos toda la justificación de utilizar los bloqueos y pierde sentido el control que queremos realizar.

La respuesta es que podemos evitar que cualquier usuario realice la modificación de los bloqueos (tanto establecerlos como eliminarlos), utilizando los objetos de autorización

Con el objeto de autorización V_VBAK_AAT (lo podéis consultar utilizando la transacción SU21, en la sección SD), podemos restringir, por clase de documento, si un usuario puede bloquear un pedido (tanto bloqueo de entrega como de factura) o si tiene autorización para eliminar el bloqueo.

Truco111_img11

Para mi ejemplo, he preparado un rol especifico para un usuario al cual le dejo crear pedidos, pero no le permito ni bloquear ni liberar documentos. He utilizado la transacción PFCG para crear el rol, dándole acceso a las transacciones de creación de pedidos (VA01/VA02/VA03) e indicando para el objeto V_VBAK_AAT los siguientes valores:

Truco111_img12

Vemos que la autorización se define por clase de documento, por lo que podremos realizar distintas estrategias según la clase de documento concreta (por ejemplo, los documentos de venta normal por un lado (TA), solicitudes de cargo a abono por otro (G2,L2), las devoluciones, etc).

Al asignar el rol al usuario, este intenta modificar un pedido existente y quitar el motivo de bloqueo de entrega, el sistema le mostrará el mensaje “Ud. NO está autorizado para desbloquear!”.

Truco111_img13

Lo mismo, en este caso, si el usuario intenta bloquear un pedido ya liberado, el campo de  Bloqueo esta cerrado y el usuario no podrá indicar un motivo de bloqueo.

Truco111_img15

Podemos consultar con la transacción SU53 los objetos de autorización verificados que han impedido al usuario realizar la acción (en este caso, para liberar necesitaba autorización a la actividad 43 para la clase de documento G2, pero carecía de ellos en los roles de autorización que tenía asignados).

Truco111_img14

Jugando con las actividades ’05 – Bloquear’ y ’43 – Liberar’ podremos montar los roles de autorizaciones con las acciones concretas que podrá realizar cada usuario. Por ejemplo, un backoffice que crea los pedidos tendrá seguramente autorización para crear documento y bloquearlos, pero nunca para quitar un bloqueo.

Un superusuario o responsable tendrá acceso a todas las actividades. Un responsable comercial quizás tendrá acceso a liberar determinadas clases de pedido, según su área de responsabilidad.

Otras maneras de gestionar bloqueos en los documentos de venta.

Si lo que necesitamos es establecer en un documento de venta bloqueos que sean supervisados o liberados por varios usuarios, la funcionalidad de bloqueo no será suficiente y tendremos que utilizar los “Esquemas de Status” asociados al documento.

lib_pvta1

Con esta funcionalidad podemos asociar al documento (a nivel de cabecera o para cada posición), una secuencia de estados. Resumiendo, los que nos permite SAP en este caso:

  • Definir una secuencia de estados asociados al documento a posición.
  • Definir la forma de hacer la transición de los estados hacia adelante o hacia atrás (anulación de la liberación).
  • Controlar las acciones que se pueden hacer con los documentos en cada estado: facturar, entregar, crear un documento posterior.

lib_pvta9

  • Delimitar que usuario puede asignar cada status: de esta forma solo el liberador podrá mover el documento a un estado determinado.

En una entrada anterior del blog explicamos en profundidad como configurar esta funcionalidad estándar y todos los detalles a tener en cuenta.

lib_pvta6

Al final quedo una entrada un poco larga, pero había muchos puntos que aclarar sobre el tema de hoy. Espero que os sea de utilidad.

Bibliografía:

Gracias como siempre a Anupa Wijesinghe por la información que comparte en su blog learnsaptips.com:

http://www.learnsaptips.com/2019/11/deactivate-sales-order-block-removal.html

https://saptricks.wordpress.com/2013/03/09/truco-48-liberacion-en-pedidos-de-ventas/

Si queréis saber más sobre autorizaciones os recomiendo la lectura de estos dos posts anteriores del blog:

https://saptricks.wordpress.com/2013/03/22/truco-49-autorizaciones-desde-el-modulo-de-organizacion-roles-de-usuario-con-pfcgi/

https://saptricks.wordpress.com/2013/03/24/truco-50-autorizaciones-desde-el-modulo-de-organizacion-ppocw-y-ppomw-y-ii/

https://saptricks.wordpress.com/2011/06/26/truco-14-analisis-de-autorizaciones-traza/

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

Truco 110. Ampliación del maestro de clientes. Configuración de mensajes estándar para chequeos.


En varias entradas anteriores del blog vimos varias formas de personalizar el maestro de clientes. 

  • Chequeos personalizados:  usando la ampliación SAPMF02D (CMOD), podiamos añadir nuestra propias verificaciones en la creación o modificación de clientes. Por ejemplo, control de NIF duplicados, verificación de valores o chequeo de dependencias entre ellos, etc. Ver información completa en el enlace.

truco7_3

  • Inicializar valores por defecto al crear un cliente: en una entrada posterior hablamos de la forma de poder dar valores por defecto en la creación de los clientes, utilizando la Badi CUSTOMER_ADD_DATA.   Utilizando el método PRESET_VALUES_CCODE podemos inicializar valores a nivel de sociedad y con el método PRESET_VALUES_SAREA podemos inicializar valores a nivel de organización de ventas. Ver información en el enlace.

Truco110_img1

Esto es muy útil, pues nos permite definir valores por defecto en la condición de pago, via de pago, grupo de tesoreria, etc, por ejemplo, al crear un cliente (por grupo de cuentas, por país, etc). En la badi tenemos disponible la información introducida hasta el momento por el usuario (KNA1, KNB1 o KNVV) y podemos hacer las inicializaciones deseadas.

Añadir campos adicionales en el maestro de clientes

Si lo que necesitamos es añadir nuestros propios campos en el maestro de clientes, podemos utilizar igualmente la Badi CUSTOMER_ADD_DATA, en combinación con la badi CUSTOMER_ADD_DATA_CS.  Con esta ultima gestionamos añadir las pantallas en la transacción, en combinación con la otra BADI donde gestionamos la gestión de los datos.

Os recomiendo la lectura del blog saptechnical.com , donde se explica paso por paso todas las tareas de programación a realizar para realizar la ampliación. En mi ejemplo, siguiendo las indicaciones, he añadido una nueva sección de datos (aparecerá un botón en la parte superior de la pantalla, debajo del titulo).

Truco110_img5

Al seleccionarlo, nos llevará nuestra pantalla de datos propios, donde incluiremos los campos necesarios.

Truco110_img6

En la Badis, con la ayuda de un abaper, incluiremos la lógica de comprobación de los datos así como el guardado en la base de datos (como una extensión de las tablas de cliente o en tablas Z).

En cualquier caso, antes de ampliar el maestro recomiendo utilizar los campos disponibles en el estándar (que son muchos), incluso utilizar el sistema de clasificación, que también nos permite definir campos a completar en el maestro sin necesidad de programar (utilizando las clases).

Truco110_img7

En la imagen podéis ver la asignación de una clase sencilla con dos características al cliente para indicar información adicional. Sin necesidad de programar y con búsquedas disponibles en el estándar por defecto. Hablaremos de esto en una próxima entrada el blog.

Verificación de clientes utilizando los mensajes estándar

Para terminar, como bien nos explica Anupa Wijesinghe en su blog, y para completar las posibilidades de personalización, existe una forma estándar de controlar algunas situaciones relacionadas con el maestro de clientes, sin necesidad de programar. En la ruta de customizing Logística en general –> Interlocutor comercial –> Clientes –> Control –> Modificar control mensajes para maestro deudores.

Truco110_img2

Existe una gran cantidad de mensajes que se pueden configurar, pero me han parecido especialmente interesantes los que nos permiten controlar la duplicidad de identificador fiscal ( mensajes 272 o 273) o la duplicidad de direcciones (que nos puede avisar de la duplicidad de un cliente, mensaje 145).

Truco110_img3

Para el ejemplo, he configurado el mensaje 145 como activado (tipo de mensaje I, se mostrará un pop-up). Al crear un cliente nuevo o modificar uno ya existente, si existen uno o varios clientes con la misma dirección (nombre, domicilio, etc), el sistema muestra un aviso y nos enseña la lista de los clientes con los mismos valores.

Truco110_img4

Una funcionalidad interesante, aunque limitada si queremos lógicas de comprobación más complejas. En ese caso, utilizaremos las opciones descritas anteriormente.

Espero que os sea de utilidad.

Bibliografía:

http://www.learnsaptips.com/2020/01/message-control-settings-for-customer.html

http://saptechnical.com/Tutorials/ABAP/XD01/XD01.htm

http://abaperitos.blogspot.com/2009/03/badis-programacion-abap.html

https://www.apprisia.com/blog/sap-abap/learn-how-to-enhance-xd02-in-5-simple-steps-2/

 

 

Publicado en Abap, Formacion, Sap FI, Sap SD | Etiquetado , , , | Deja un comentario

Truco 109. Verificaciones de cliente en la transacción MIGO


En nuestro truco de hoy vamos a hablar de la transacción MIGO y de como incluir chequeos propios en la transacción, cuando queramos realizar nuestras propias comprobaciones fuera del estándar.

¿Que es la transacción MIGO?

La transacción MIGO es una transacción enjoy diseñada para realizar los movimientos de material en el sistema (modulo MM). Vino a sustituir a un conjunto de transacciones especializadas en cada clase de movimiento que existían en versiones anteriores.

Por ejemplo, la MB01, MB1A, MB1B, MB1C, son algunas de las transacciones previas.

Truco109_img1

Transacción MB1A para realizar salidas de mercancía

Todas estas transacciones quedarán obsoletas con S4/HANA y ya no será posible utilizarlas mas.

Cuando Sap desarrolló la MIGO intento mejorar la experiencia de usuario y que la mayoría de operaciones relacionadas con gestión de stocks se pudieran realizar desde una única interfaz de usuario.

Truco109_img2

Transacción MIGO

La transacción es dinámica y varia su contenido según el tipo de operación  y la clase de movimiento de material que estemos realizando. Además, tenemos todos los campos disponibles en una única pantalla con diferentes secciones.

¿Como personalizar la transacción?

Mediante parametrización, se puede modificar el comportamiento de algunos campos, según cada clase de movimiento. Por ejemplo, podemos hacer un campo opcional u obligatorio.

Truco109_img3

Configuración de campos en la MIGO por clase de movimiento

Las parametrizaciones relacionadas con la MIGO las tenéis en la ruta: Gestión de materiales –> Gestión de stocks e inventario –> Parametrizaciones para transacciones Enjoy –> Parametrizaciones para movimientos de mercancia (MIGO).

Por ejemplo, también podréis hacer obligatorios campos a nivel de cabecera en la transacción.

Ademas, mediante programación podemos en la transacción MIGO añadir nuestro propios campos si fuera necesario. Para ello podéis utilizar la BADI MB_MIGO_BADI que permite realizarlo. Os dejo un vídeo de como hacerlo. En la sección de Bibliografia tenéis dos ejemplos más de personalización utilizando esta BADI.

¿Como incluir nuestras propias validaciones?.

Si lo que necesitáis hacer es añadir verificaciones adicionales en la transacción, la alternativa sería utilizar la BADI MB_MIGO_ITEM_BADI. Algunas consideraciones sobre esta BADI:

  • La badi es llamada cuando una nueva linea es insertada en la MIGO o cuando una linea existente se modifica.
  • Si los cambios se realizan en la cabecera, no se llama a la BADI si no hay cambios en las posiciones.
  • Toda la información de la cabecera y de las posiciones es transferida a la BADI para que pueda ser utilizada para realizar las comprobaciones.
  • En la BADI se puede ademas realizar la modificación del almacén o del texto de posición.

En mi ejemplo, estoy verificando que posiciones de pedido que se gestionan con entrega entrante no se contabilice la entrada de mercancía desde la MIGO, sino desde la VL32N.

Truco109_img4

Estos son los parámetros que se pueden gestionar en la BADI:

Truco109_img6

En la estructura ET_RETURN podemos pasar los mensajes que queremos que se devuelvan al usuario (E Error, W Warning, etc).

Cuando estoy en la transacción, al intentar hacer el movimiento de mercancía, se realiza la comprobación y se dispara el error:

Truco109_img5

Podríamos haber utilizado igualmente la BADI MB_CHECK_LINE_BADI método CHECK_LINE, pero a mi me parece más sencilla la implementación que os he mostrado. Podéis ver un ejemplo de implementación en este enlace de implementación.

Espero que os sea de utilidad.

Bibliografia:

https://blogs.sap.com/2013/06/14/how-to-create-a-custom-tab-for-migo-item-details/

Video: Add Custom Tab Screen in MIGO

http://saptechnical.com/Tutorials/ExitsBADIs/MIGO/screenexit.htm

BAdI MB_MIGO_BADI – In the middle of nowhere: http://scn.sap.com/docs/DOC-68084

https://blogs.sap.com/2018/11/21/adding-multiple-messages-in-migo-transaction-via-mb_check_line_badi/

En el libro “ABAP Development for Materials Management in SAP: User Exits and Badis” de Jürgen Schwaninger (Sap Press), tenemos ejemplos de código de la badi Ejemplos de código de la Badi MB_MIGO_BADI, para añadir campos de cliente en la transacción MIGO así como para realizar chequeos con el método MB_MIGO_ITEM_BADI (páginas 125 a 127). Os recomiendo la lectura de la versión parcial de este libro disponible gratuitamente.

Haz clic para acceder a 373_ucg.pdf

 

 

Publicado en Abap, Formacion, SAP MM | Etiquetado , , , | Deja un comentario

Truco 108. Motivo de rechazo en pedidos de venta.


En tiempo difíciles seguimos al pie del cañón compartiendo conocimiento. Las cosas se están poniendo muy feas en España, como en Italia y parece que va llegando a otros países. Así que cuidaros y no salgáis a la calle más que para lo estrictamente necesario. Como decía ayer un militar, cada persona que no sale es un virus menos que encuentra “huésped” para poder seguir viviendo y haciendo daño. Es un trozo de batalla ganada. Espero que estáis bien, de verdad.

En el post de hoy vamos a hablar de la forma de concluir pedidos de venta. Por diferentes circunstancias, uno o varias posiciones de un pedido de venta pueden no suministrarse o los servicios descritos en ellas no ser llevados a cabo. Por ejemplo:

  • Roturas de stock: no tenemos disponibilidad de la mercancía. Tenemos problemas de suministro por parte de nuestros proveedores o en los mismos procesos de producción dentro de la compañía. Estos materiales puede que nunca se suministren o simplemente haya un retraso en la entrega hacia una fecha posterior.
  • Productos obsoletos: en ocasiones cambian los catálogos de productos o servicios. Un pedido se registra con una referencia anterior, que será posteriormente sustituida en el pedido por un articulo o servicio diferente.
  • Anulación del pedido: el cliente nos comunica la cancelación de un pedido que todavía no se ha suministrado.
  • Cambios en los pedidos: el cliente nos comunica cambios en el pedido, posiciones que no desea que se suministren, corrección de errores, etc.

Seguro que se os ocurren muchos más ejemplos.En estos casos podríamos decidir eliminar las posiciones del pedido, incluso el documento completo, pero perderíamos la trazabilidad de las operaciones gestionadas con nuestro clientes. Para evitar esto, Sap nos proporciona el Motivo de rechazo (Reject reason en Ingles), para poder gestionar situaciones como estas.

El motivo de rechazo se gestiona a nivel de posición, teniendo disponible una actualización en masa dentro de la transacción VA01/VA02 para poder rechazar posiciones de forma colectiva.

Truco108_img1

Podemos parametrizar tantos motivos de rechazo como necesitemos para identificar cada posible situación que queramos tener identificada.

¿Por que es necesario rechazar las posiciones?

Las posiciones rechazadas no se van a continuar gestionando en el flujo logístico. Por tanto, no se realizará su entrega ni tampoco su facturación (incluso en posiciones no susceptibles de entrega como servicios, notas de cargo o abono, etc).

Si no utilizáramos un motivo de rechazo, los documentos se quedarían “abiertos” indefinidamente y nos molestarían en los diferentes procesos. Igualmente impedirían en el futuro tareas como las de archivado (borrado físico de los documentos de la base de datos).

Por ejemplo, un pedido en el que he facturado 4 posiciones, pero me he dejado 1 abierta, tiene este status en el flujo de documentos:

En cambio, si rechazamos la posición que no hemos podido servir al cliente, la situación sería esta:

El documento se da por concluido y ya no nos aparecerá como pendiente en nuestras transacciones estándar (VA05, VA05N, VA06) o en los informes Z que hayamos desarrollado en nuestra instalación.

Además, a nivel de tablas tenemos una forma fácil de consultar si en un documento hay posiciones rechazadas (tanto a nivel de cabecera, con la tabla de status VBUK, como a nivel de posición con la tabla VBUP).

Parametrización de los motivos de rechazo

Los motivos de rechazo se configuran desde la transacción OVAG o en la ruta de customizing Comercial –> Ventas –> Documentos de Ventas –> Posición documento ventas –> Definir motivos de rechazo.

Basicamente indicamos un código y su correspondiente descripción.

Ahora, en este punto, nos hacemos una pregunta. ¿Que ocurre con el importe de las posiciones rechazadas en un pedido? ¿Acumula al total del pedido?. La respuesta es: depende de como hayamos configurado el motivo de rechazo, en concreto el campo “Estad” en la configuración.

Si dejamos el valor en blanco, el importe si se acumula, aunque las posiciones estén rechazadas (esto no significa que se vaya a facturar). Esto podría darnos información sesgada en los informes o dar lugar a análisis incorrectos. Por ejemplo, en mi pedido:

Truco108_img6

La posición 10, rechazada, esta sumando su importe al valor neto del pedido. Por tanto, en la configuración de los motivos de rechazo nunca se debería de dejar el valor en blanco para evitar esto.

Los correcto sería utilizar uno de los dos valores siguientes en la configuración:

  • X: no se acumula importe al valor neto del pedido. Pero si se puede añadir a los importes del sistema info de ventas (LIS/SIS).
  • Y: no se acumula importe al valor neto del pedido ni tampoco a los importes del sistema info de ventas.

De esta forma, nos aseguramos que los importes de posiciones rechazadas no se suman al total del pedido.

En nuestro ejemplo, un motivo de rechazo con el valor X no incrementa el importe neto del pedido.

Truco108_img7

Espero que os sea de utilidad.

Bibliografía:

https://blogs.sap.com/2012/06/28/ignore-net-value-of-rejected-item-from-total-sales-order-value/

 

Publicado en Formacion, Sap SD | 2 comentarios

Truco 107. Trabajando con calendarios en SAP. Calculo de dias.


En nuestro truco de hoy vamos a hablar de los calendarios de SAP, como podemos utilizarlos en diferentes ámbitos y algún truco de programación para leer la información registrada en ellos.

Básicamente, estamos hablando de una funcionalidad transversal (utilizada en muchos módulos), que nos permite indicar los días que son hábiles o no para diferentes procesos.

Donde podemos utilizar los calendarios.

Algunos ejemplos de utilización de los calendarios son los siguientes:

  • Calendario asociado a un centro: nos permite indicar los días que son hábiles para el centro, siendo utilizada la información en el cálculo de planificación de necesidades, programación de ordenes, etc.
Asignación de calendario a centro (transacción OX10)
  • Calendario asociado a un puesto de expedición: asociado a un puesto de expedición nos permite indicar los días laborables en los procesos de preparación de pedido (se utilizará en la verificación de disponibilidad de los pedidos y en el calculo de la programación de los pedidos). En los puesto de expedición podremos afinar aún mas indicando horarios y turnos de trabajo.
Asignación de calendario a puesto de expedición (transacción OVLZ)
  • Calendario asociado a rutas: indicando un calendario en una ruta, podemos indicar los días en los que realmente trabaja la ruta, siendo tenido en cuenta para la planificación de la entrega.
Definición de rutas en el customizing (transacción 0VTC)
  • Calendarios de facturación: nos permite indicar, por cliente, los días que son hábiles para la emisión de facturas. Se utilizará para llenar la propuesta de fecha de factura en los pedidos de venta que creemos. Por ejemplo, si un cliente nos exige facturación mensual (último día de mes), podremos gestionar esta necesidad utilizando calendarios.
Asignación de calendario a cliente en los datos de ventas (transacción XD02)
  • Calendarios para la gestión de rappels de ventas: tanto en la parametrización de los rappels como en la definición de acuerdos se pueden indicar calendarios de rappels para indicar los días previstos de liquidación o para realizar la prolongación automática de acuerdos.
  • Calendarios laborales para planificación de jobs: podemos utilizarlos igualmente cuando planificamos jobs en el sistema para indicar las fechas en las que se ejecutaran los procesos o evitar que se realicen en determinados momentos.
Utilización de calendario para restricciones de ejecución al crear un job
  • Desarrollos a medida: los calendarios pueden utilizarse en desarrollos Z para reporting o controlar procesos. Por ejemplo, un calendario donde indicamos los dias de trabajo de los comerciales para hacer cálculo de previsiones y grado de previsiones cumplidas según los días de venta.

Configurando los calendarios.

La configuración de los calendarios se realiza utilizando la transacción SCAL. Hemos de distinguir 3 componentes en la definición de calendarios:

  • Festivos: podemos predefinir los días festivos utilizando reglas y luego incluirlos en el calendario de festivos para que el cálculo de los festivos se haga de forma automática.
  • Calendario de festivos: no es más que una recopilación de festivos. Los calendarios de festivos se asocian posteriormente a los calendarios de fábrica.
  • Calendario de fábrica: el calendario de fábrica es el elemento que nosotros asignamos en la parametrización o funcionalidad, y consiste en un conjunto de días que se consideran hábiles según la definición realizada, a partir de días laborables en general, calendario de festivos y excepciones o reglas especiales.

Veamos un poco más en detalle cada uno de estos elementos.

Con la opción “Días festivos” realizamos la definición individual de los diferentes festivos que podemos tener en nuestro sistema. No es imprescindible utilizarlo, aunque si facilita la automatización del mantenimientos de los calendarios de fábrica.

Básicamente, al crear un festivo el sistema nos pedirá la definición de su tipología, teniendo disponibles 5 opciones.

En detalle:

  • con fecha fija: se indica una fecha (mes y día) que siempre es festivo en un determinado ámbito. En este caso se puede determinar como se comporta el festivo si cae en un determinado día, por ejemplo, un domingo (con las opciones de garantía)
  • con día fijo a partir de esta fecha: se indica una fecha y el día de la semana a partir de esa fecha que aplicará el festivo.
  • Distancia Pascuas: para calcular los festivos asociados con la semana santa (que varían cada año). Se puede indicar un número de días antes del domingo de Pascua (por ejemplo, para calcular el jueves o viernes santo) o un numero de días a posteriori (por ejemplo para el lunes santo).
  • Domingo de Pascua: idem del anterior, en este caso para identificar el Domingo de Pascual, que es variable cada año como hemos indicado.
  • Festivo irregular: puede haber festivos que sean irregulares y que dependiendo del año aplican o no. Con esta definición de festivo, podemos definir la relevancia del festivo matizándolo con el año. Por ejemplo, en la ciudad de Alicante el día 25 de junio es festivo algunos años. Con este tipo de festivo podríamos definir esa casuística.

Además a cada festivo se le puede asignar una descripción, un texto breve y una clave de clasificación (para que sea más fácil relacionar los festivos asociado, por ejemplo a un país, categoría de festivo, religión, etc).

Una vez definidos los diferentes festivos, los agruparemos creando un “Calendario de festivos”. El calendario de festivos tiene un periodo de validez (año inicial y año final) y en el se enumeran los diferentes festivos asociados (igualmente indicando un intervalo de validez en la asociación de cada día festivo al calendario de festivos).

Definición de calendario de festivos

Con la opción Visualizar Calendario podríamos vez como quedaría la asignación de festivos en un calendario de fechas real.

Finalmente, procederemos a la creación del “Calendario de fábrica”. En la definición de un calendario de fábrica hemos de indicar es su periodo de validez, el calendario de festivos asociado (que habremos definido previamente) y los días que se consideran laborables.

Definición de un calendario de fábrica

La definición de días laborables dependerá si la empresa trabaja todos los días de semana, solo de lunes a viernes, etc (y del ámbito donde vayamos a utilizar el calendario). Una vez definido el calendario, ya podremos consultar su configuración con un calendario de fechas utilizando la opción Calendario.

El sistema nos mostrará un resumen por año con la cantidad de días laborables y festivos, pudiendo entrar a visualizar el detalle de cada año (apareciendo en naranja los días laborables y en verde los días festivos).

Si necesitamos definir reglas especiales para determinados días en un año, podemos realizarlo utilizando la opción “Reglas especiales”. Por ejemplo, para mi calendario de facturación mensual, donde solo el último día de cada mes es “laborable”, he definido reglas especiales para esos días, que me permiten indicar los días que son relevantes (el resto de días por el calendario de festivos asignado o por la definición de días laborables son no laborables).

Si no hubiera marcado el flag de “Dia labor.” estaría añadiendo con las reglas especiales días festivos o excepciones adicionales. Es otra manera más sencilla de definir los festivos de un años, aunque habrá que acodarse cada año de definirlos como excepciones.

Transporte de calendarios.

Respecto al transporte de los calendarios, aunque se puede realizar desde la SCAL de forma estándar, el transporte borra todos los calendarios existentes en el sistema destino, por lo que mi recomendación es realizar la configuración en cada sistema (abriendo el mandante con la transacción SCC4).

Este es el texto que muestra Sap cuando pulsamos la opción de transportar. Como podéis observar, no es nada tranquilizadora la forma en la que el estándar realizar dicho transporte.

Leyendo los calendarios en nuestros desarrollos.

Si necesitamos disponer de la información de los calendarios en nuestros desarrollos, es muy sencillo hacerlo utilizando diferentes módulos de función estándar.

Por ejemplo, con el MF HOLIDAY_GET, indicando el periodo que queremos analizar y el calendario de fábrica.

El sistema nos devuelve la lista de días que son no laborables (por ser festivos o días considerados no hábiles en el calendario de fábrica).

Resultado de la ejecución del módulo de función HOLIDAY_GET

Otro módulo de función interesante es el DAY_ATTRIBUTES_GET, que nos permite obtener los parámetros para un día o un intervalo de fechas (si el día es laboral o no, si es un festivo, etc).

Resultado de la ejecución del módulo de función DAY_ATTRIBUTES_GET

Si necesitáis ampliar información, os recomiendo la lectura de los links que se anexan a continuación.

Bibliografía.

https://blogs.sap.com/2016/03/20/step-by-step-getting-working-days-from-sap-calendars-by-universe-on-sap-erp/

https://blogs.sap.com/2015/03/10/significance-of-calendar-in-sap-logistics/

https://blogs.sap.com/2014/02/13/public-holiday-calendar-and-work-schedule-rules/

https://wiki.scn.sap.com/wiki/display/NWTech/SAP+Calendar+Master

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

Truco 106. Personalización de la transacción MD04 (Lista de necesidades).


En nuestro truco de hoy volvemos a temas más funcionales y vamos a hablar un poco de la transacción MD04.

Esta transacción es uno de los pilares fundamentales para el trabajo de los planificadores en un sistema Sap o de las personas que se encargan de los procesos de compra.

Básicamente, la MD04 nos permite, a partir de un material en un centro determinado, visualizar los elementos de planificación existentes en el momento actual.

Por ejemplo, al ejecutar la transacción podremos visualizar los stocks existentes en el centro, entradas previstas (solicitudes de pedido, pedido), ordenes de producción, ordenes previsionales, reservas, documentos de salida (pedidos de cliente, entregas), pedidos de traslado, etc.

Si un material es requerido para otro proceso (por ejemplo, es componente de la lista de materiales de un material que se fabrica o se utiliza como componente de subcontratación), también aparecerán las necesidades secundarias que son disparados por la necesidad de otro producto.

Igualmente, si en nuestro sistema introducimos necesidades planificadas desde el módulo de Producción, podremos verlas como un elemento de planificación.

Los diferentes necesidades aparecen ordenadas por fecha, está identificada su tipología por el campo “Elemento Planificación” (os recomiendo echar un vistazo a la ayuda del campo en cuestión).

La transacción MD04 nos permite navegar por los elementos (haciendo doble clic en ellos). Incluso permite realizar acciones (por ejemplo, nos permite crear un pedido a partir de una solped o crear una orden de producción a partir de una orden previsional). Por ejemplo, desde una solicitud de pedido

La transacción nos permite visualizar las necesidades de forma detallada o de forma agrupada por periodos (días, semanas o meses). Esto nos permite analizar de forma fácil periodos del futuro, detectando infracoberturas, problemas con los stock en determinados periodos, etc.

La transacción dispone de muchas utilidades, como el poder realizar filtrado en los elementos que se visualizan (hay que habilitar el filtrado pulsando el botón del filtro).

Además Sap nos deja ciertas “puertas abiertas” para realizar una personalización de la transacción, que es lo que os voy a contar en nuestro truco de hoy.

Transacciones adicionales en la barra de botones.

Podemos añadir, por parametrización, acceso directos a transacciones relacionadas por poder ser llamadas directamente cuando estemos dentro de la MD04.

La parametrización se realiza con los llamados “Perfiles de navegación”, desde la transacción OM0K, opción “Llamadas de transacción generales”. teniendo una limitación de 5 botones. Básicamente definiremos un perfil de navegación (hay unos estándar y podremos añadir los Z que deseemos).

Para cada botón, indicaremos la transacción que será llamada, pudiendo personalizar el icono asociado, pasar parámetros de memoria o filtrar la disponibilidad del botón según determinados valores del maestro del material (clase de aprovisionamiento, tipo de material, grupo planificación o característica de planificación).

Opciones adicionales en cada elemento de planificación.

Utilizando igualmente los perfiles de navegación, podemos añadir, para cada elemento de planificación, botones de navegación hacia otras transacciones.

Por ejemplo, si estamos en una solicitud de pedido, podremos añadir una llamada a Liberar la solicitud de pedido (ME54) o enviar un email al proveedor ( MDM2).

En la transacción OM0K seleccionaremos un Perfil de navegación y añadiremos las diferentes opciones en la sección “Llamadas transacción por elemento planificación”. Por ejemplo, en mi perfil para el elemento de planificación BA (Solicitud de pedido), hemos añadido las dos opciones indicadas (Liberar solped y Enviar email).

La forma de hacer accesibles los botones, tanto a nivel de barra de botones, como por elemento de planificación es seleccionando uno de estos perfiles cuando estemos trabajando con la MD04. Para ello, seleccionaremos la opción de menú Entorno –> Perfil de navegación –> Asignar.

Desde aquí podremos seleccionar el perfil de navegación que deseemos utilizar en cada momento o guardarlo como valor por defecto para el usuario con el que estemos trabajando.

Añadir columnas adicionales en la MD04.

Sap nos permite, mediante user-exit o Badi, añadir hasta 3 columnas adicionales en la transacción MD04. Puede ser útil cuando tenemos que añadir información extra en el informe que sea requerida por nuestros usuarios.

Podemos hacerlo a través de la CMOD (ampliación M61X0002), donde podemos llenar el valor de uno de estos 3 campos adicionales. Hay un ejemplo de implementación en el estándar.

Si preferimos utilizar las Badis, realizaremos una implementación de la badi MD_ADD_COL_EZPS (usando los metodos ACTIVATE_ADD_COLUMNS  y FILL_ADD_COLUMNS). Ver ejemplo de implementación en este link (gracias a saptutorial.org).

Desarrollos Z con información de la MD04.

Para finalizar, en ocasiones se nos hace necesario desarrollar un report Z que tenga la información de la MD04, pero con la opción de poder incluir varios materiales a la vez, filtrar por el tipo de elemento de planificación, etc. Es relativamente sencillo utilizando el módulo de función MD_STOCK_REQUIREMENTS_LIST_API. Aquí os pego un trozo de código con lo que haría falta.

* Pasamos la regla de seleccion ERGBZ

    CALL FUNCTION ‘MD_STOCK_REQUIREMENTS_LIST_API’
      EXPORTING
        plscn                    = plscn
        matnr                    = it_marc-matnr
        werks                    = it_marc-werks
      IMPORTING
        e_mt61d                  = wa_mt61d
        e_mdkp                   = wa_mdkp
        e_cm61m                  = wa_cm61m
        e_mdsta                  = wa_mdsta
*       e_ergbz                  = wa_ergbz
      TABLES
        mdpsx                    = it_mdps
        mdezx                    = it_mdez
        mdsux                    = it_mdsu
      EXCEPTIONS
        material_plant_not_found = 1
        plant_not_found          = 2
        OTHERS                   = 3.

Datos que devuelve:
  DATA:
    wa_mt61d TYPE mt61d,
    wa_mdkp  TYPE mdkp,
    wa_cm61m TYPE cm61m,
    wa_mdsta TYPE mdsta.

Tablas que devuelve:
  DATA:
*”  TABLES
    it_mdps TYPE TABLE OF mdps WITH HEADER LINE,
    it_mdez TYPE TABLE OF mdez WITH HEADER LINE,
    it_mdsu TYPE TABLE OF mdsu WITH HEADER LINE.

Se le pasa la información del material y centro (se hace una iteracion para los diferentes materiales y centros para los que se quiera obtener los datos).
En la tabla it_mdez está el detalle de los elementos que aparecen en la MD04, pudiendo completar la información devuelta por el estándar con cualquier otra información adicional que se quisiera mostrar.

Espero os sea de utilidad.

Bibliografía:

https://blogs.sap.com/2013/06/15/icons-for-frequently-used-transactions-in-md04/

https://vdocuments.mx/md04-add-new-columns.html

https://www.saptutorial.org/add-custom-column-in-sap-md04-tcode/

Publicado en Abap, Formacion, SAP MM, Sap PP | Etiquetado , , , , | 2 comentarios

Truco 105. Envío de email con resultados de un ALV.


En nuestro truco de hoy inauguramos una sección donde propondremos típicos ejemplos prácticos de necesidad funcional y como solucionarlos, incluyendo en muchos casos elementos de programación Abap.

Empezaremos con un ejemplo clásico donde necesitamos que un report Z envie por email los resultados calculados y que en modo interactivo se muestran en un ALV. Por ejemplo, en una ejecución del programa en fondo queremos que se envíen los resultados a uno o varios usuarios. O incluso el mismo usuario que esta viendo los resultados de forma interactiva quiere enviar la información a otro usuario de la empresa o un contacto externo (cliente o proveedor).

Para nuestro ejemplo, partimos de un desarrollo Z que nos permite listar información de pedidos de compra.


En el informe añadiremos en los criterios de selección del programa añadiremos un campo para poder introducir los destinatarios de email donde queremos enviar los resultados del ALV ( Select-options: so_email for adr6-smtp_addr. )

Y un botón para que el usuario, cuando lo desee, pueda lanzar el envío del correo electrónico que contendrá como anexo una excel con la información.

Ahora, la parte más compleja. La programación necesaria para convertir la tabla interna que estamos utilizando en el ALV en una hoja excel, construir el correo electrónico y enviarlo a los destinatarios.

Básicamente, utilizamos los siguientes elementos de programación:

  • Clase cl_salv_bs_tt_util: nos permite convertir una tabla interna a formato excel.
  • Clase cl_bcs: para gestionar el envío del correo.
  • Clase cl_document_bcs: para crear el correo, indicar asunto y texto, anexar excel, etc.

En mi programa, he creado un FORM que se ejecuta cuando el usuario pulsa el botón de enviar correo, que se llama lanza_envio_mail.

Desde allí se llama a send_email donde se hace todas las operaciones técnicas de convertir la tabla interna a un xls (form f_build_email_data ) y la construcción del correo electrónico.

FORM lanza_envio_email.
* miro si la tabla de emails esta vacia, intento meter el email del user
  DESCRIBE TABLE so_email LINES lv_num_emails.
  IF lv_num_emails = 0.
    SELECT SINGLE adr6~smtp_addr INTO so_email-low
         FROM usr21
           INNER JOIN adr6
              ON  usr21~addrnumber = adr6~addrnumber
             AND usr21~persnumber = adr6~persnumber
                 WHERE bname = sy-uname.
    IF sy-subrc EQ 0.
      lv_num_emails = lv_num_emails + 1.
      so_email-sign = ‘I’.
      so_email-option = ‘EQ’.
      APPEND so_email.
    ENDIF.
  ENDIF.
  IF lv_num_emails > 0.
* Construimos el catalogo para poder hacer la excel.
    CALL FUNCTION ‘LVC_FIELDCATALOG_MERGE’
      EXPORTING
        i_structure_name       = ‘ZME2L’
      CHANGING
        ct_fieldcat            = gt_fieldcat
      EXCEPTIONS
        inconsistent_interface = 1
        program_error          = 2
        OTHERS                 = 3.
    PERFORM modify_fieldcat.
* Constuimos el correo desde la tabla interna.
    PERFORM send_email.
  ENDIF.
ENDFORM.

*&———————————————————————*
*&      Form  SEND_EMAIL
*&———————————————————————*
*       text
*———————————————————————-*
*  –>  p1        text
*  <–  p2        text
*———————————————————————-*
FORM send_email .
  DATA:
    lt_binary_content TYPE solix_tab,
    lv_size           TYPE so_obj_len,
    r_mail            TYPE ace_generic_range_t,
    st_mail           TYPE ace_generic_range,
    lv_count          TYPE char2,
    lv_var            TYPE char8.
  FIELD-SYMBOLS: <fs_mail> TYPE any.
  REFRESH: lt_binary_content.
  CLEAR: st_mail, lv_count, lv_var.

* Construye el objeto binario de la excel a partir de la tabla interna
  PERFORM f_build_email_data CHANGING lt_binary_content
                                       lv_size.
  DATA: v_rundate        LIKE sy-datum,
        v_runtime        LIKE sy-uzeit,
        timestamp(20),
        lcl_send_request TYPE REF TO cl_bcs,
        lcl_document     TYPE REF TO cl_document_bcs,
        lv_subject       TYPE so_obj_des,
        lt_main_text     TYPE soli_tab,
        lv_text          TYPE soli,
        lv_filename      TYPE sood-objdes,
        lv_mailto        TYPE adr6-smtp_addr,
        lcl_recipient    TYPE REF TO cl_cam_address_bcs,
        lv_sent_to_all   TYPE os_boolean.

*–Run Date and Run Time
  v_rundate = sy-datum.
  v_runtime = sy-uzeit.
*  CONCATENATE v_rundate v_runtime INTO timestamp.
  WRITE sy-datum TO timestamp MM/DD/YYYY.
  TRY.
* ——– create persistent send request ————————
      lcl_send_request = cl_bcs=>create_persistent( ).

* ——– create and set document with attachment —————

* ASUNTO CORREO
      CONCATENATE ‘Informe de pedidos’  ‘ Fecha:’ timestamp
      sy-cprog sy-sysid INTO lv_subject
      SEPARATED BY space.

* Texto de correo (cuerpo del mensaje)
      CONCATENATE ‘En el Excel anexo se detallan los pedidos pendientes’
      ‘en el sistema.’ INTO lv_text SEPARATED BY space.
      APPEND lv_text TO lt_main_text.
      APPEND text-001 TO lt_main_text.
      APPEND text-003 TO lt_main_text.
      lcl_document = cl_document_bcs=>create_document(
      i_type = ‘RAW’
      i_text = lt_main_text
      i_subject = lv_subject ).                             “#EC NOTEXT

* Añadimos la excel al mensaje, poniendo nombre al fichero
      CLEAR: lv_subject.
      CONCATENATE ‘Pedidos’_’ v_rundate
      v_runtime ‘_’ sy-sysid INTO lv_filename.
      CALL METHOD lcl_document->add_attachment
        EXPORTING
          i_attachment_type    = ‘xls’
          i_attachment_subject = lv_filename
          i_attachment_size    = lv_size   “im_size
          i_att_content_hex    = lt_binary_content. “im_tab ).

* add document object to send request
      lcl_send_request->set_document( lcl_document ).

* ——— add recipient (e-mail address) ———————–
* create recipient object

*      Añadimos los destinatarios al correo
      LOOP AT so_email.
        lv_mailto = so_email-low. “ls_recipient-low.
        lcl_recipient = cl_cam_address_bcs=>create_internet_address( lv_mailto ).

* add recipient object to send request
        lcl_send_request->add_recipient( lcl_recipient ).
*        CLEAR: ls_recipient.
      ENDLOOP.
* Send now
      lcl_send_request->set_send_immediately( ‘ ‘ ).
* Outbox
      lcl_send_request->send_request->set_link_to_outbox( ‘X’ ).
* ———- send document —————————————
      lv_sent_to_all = lcl_send_request->send( i_with_error_screen = ‘X’ ).

      COMMIT WORK.

      IF lv_sent_to_all IS INITIAL.
        MESSAGE i500(sbcoms) WITH lv_mailto.
      ELSE.
        MESSAGE s022(so).
      ENDIF.

* ———— exception handling ———————————-
* replace this rudimentary exception handling with your own one !!!
*    CATCH cx_bcs INTO lcl_bcs_exception.
*      MESSAGE i865(so) WITH lcl_bcs_exception->error_type.
  ENDTRY.
ENDFORM.

FORM f_build_email_data  CHANGING p_lt_binary_content
         TYPE STANDARD TABLE
                             p_size TYPE so_obj_len.
  DATA: e_xstring TYPE xstring.
  DATA: mt_fcat     TYPE lvc_t_fcat,
        ms_fcat     TYPE lvc_s_fcat,
        st_fieldcat TYPE slis_fieldcat_alv.
  DATA: mt_data       TYPE REF TO data.
  DATA: m_flavour TYPE string.
  DATA: m_version TYPE string.
  DATA: mo_result_data TYPE REF TO cl_salv_ex_result_data_table.
  DATA: mo_columns  TYPE REF TO cl_salv_columns_table.
  DATA: mo_aggreg   TYPE REF TO cl_salv_aggregations.
  DATA: mo_salv_table  TYPE REF TO cl_salv_table.
  DATA: m_file_type TYPE salv_bs_constant.
  DATA: out_length TYPE i.
  FIELD-SYMBOLS <tab> TYPE ANY TABLE.

  CLEAR: e_xstring, ms_fcat, st_fieldcat, m_flavour, m_version,
         mo_result_data, mo_columns, mo_aggreg, mo_salv_table,
         m_file_type, out_length, mt_data.
*  REFRESH: it_fieldcat[].

*-It_final here is the final itab same parameter you pass in
* your alv grid
  GET REFERENCE OF gt_eban INTO mt_data.

*-Move your field catalog to mt_fcat make sure to populate
*-ms_fcat-seltext, because it can be that in your field cat the headings

*-are in seltext_l or seltext_m or seltext_s
  LOOP AT gt_fieldcat INTO ms_fcat.  “st_fieldcat.
*    MOVE-CORRESPONDING st_fieldcat TO ms_fcat.
*    MOVE: st_fieldcat-seltext_l TO ms_fcat-seltext.
    APPEND ms_fcat TO mt_fcat.
    CLEAR: ms_fcat, st_fieldcat.
  ENDLOOP.

  IF cl_salv_bs_a_xml_base=>get_version( ) EQ if_salv_bs_xml=>version_25 OR
     cl_salv_bs_a_xml_base=>get_version( ) EQ if_salv_bs_xml=>version_26.

    mo_result_data = cl_salv_ex_util=>factory_result_data_table(
        r_data                      = mt_data
        t_fieldcatalog              = mt_fcat
    ).

    CASE cl_salv_bs_a_xml_base=>get_version( ).
      WHEN if_salv_bs_xml=>version_25.
        m_version = if_salv_bs_xml=>version_25.
      WHEN if_salv_bs_xml=>version_26.
        m_version = if_salv_bs_xml=>version_26.
    ENDCASE.

    m_file_type = if_salv_bs_xml=>c_type_xlsx.
    m_flavour = if_salv_bs_c_tt=>c_tt_xml_flavour_export.

    “transformation of data to excel
    CALL METHOD cl_salv_bs_tt_util=>if_salv_bs_tt_util~transform
      EXPORTING
        xml_type      = m_file_type
        xml_version   = m_version
        r_result_data = mo_result_data
        xml_flavour   = m_flavour
        gui_type      = if_salv_bs_xml=>c_gui_type_gui
      IMPORTING
        xml           = e_xstring.
  ENDIF.

  CALL FUNCTION ‘SCMS_XSTRING_TO_BINARY’
    EXPORTING
      buffer        = e_xstring
    IMPORTING
      output_length = out_length
    TABLES
      binary_tab    = p_lt_binary_content.

  MOVE: out_length TO p_size.

ENDFORM.                    ” F_BUILD_EMAIL_DATA

El resultado el correo enviado podría ser algo parecido a esto, donde podemos personalizar en el código la información del asunto, texto del correo, nombre del fichero anexado, etc.

Con el fichero excel anexado con la información del ALV, todo construido con un desarrollo más o menos sencillo.

Espero que os sea de utilidad.

Bibliografia:

Gracias a Ralph Vincent Ferraren por su aporte en la Wiki del SCN de SAP:

https://wiki.scn.sap.com/wiki/display/ABAP/Send+an+Internal+Table+as+an+excel+attachment+via+email

Publicado en Abap, Formacion | Etiquetado , | Deja un comentario

Truco 104. Transporte de traducciones de textos entre sistemas.


En nuestro post de hoy vamos a hablar de como realizar el transporte este sistemas de las traducciones que podemos gestionar en los diferentes elementos de Sap (con un ejemplo concreto de traducción de un formulario Smarform).

Como todos sabéis, Sap es un sistema multilenguaje que nos permite trabajar con diferentes idiomas

Normalmente, los idiomas de logon están limitados según los países en los que utilicemos nuestro sistema Sap (por ejemplo, Español, Ingles, Alemán, Italiano, Francés), pudiéndose ampliar los idiomas disponibles con la instalación de los correspondientes paquetes de idioma.

Cuando tenemos disponibles varios idiomas, Sap nos permite traducir los diferentes elementos para que aparezcan en el idioma correspondiente cuando el usuario se conecta al sistema utilizando dicho idioma.

En la imagen, un ejemplo sencillo de traducción del campo “Lista de precios”. Al seleccionar la opción “Traducción” en las transacciones de parametrización, podemos seleccionar el idioma correspondiente e indicar el texto asociado al valor en el idioma deseado.

Esta parametrización queda registrada en la correspondiente orden de transporte, incluyendo los valores de traducción asociados al idioma correspondiente.

Sap nos facilito el trabajo al crear su sistema incluyendo en casi todos los objetos de parametrización una tabla paralela de textos (T189T en este caso), donde se pueden introducir las descripciones en los diferentes idiomas disponibles.

Cuando estamos trabajando con elementos de programación, la cosa se complica un poco más. En los programas Abap podemos traducir los textos de los elementos de selección, atributos del programa, textos de cabecera, etc, sin problema.

Si estamos trabajando con formularios, sabéis que podemos tener diferentes idiomas de comunicación con nuestros clientes o proveedores, y podemos gestionar los mensajes para comunicarlos con ellos en sus idiomas (o de forma general en ingles).

En nuestro truco de hoy nos vamos a centrar en como traducir un formulario (por ejemplo, un smartform) y luego como utilizar la herramienta de transporte de traducciones entre sistemas.

Partimos del supuesto que tenemos un formulario con la tecnología smartform ya creado para los pedidos de compra y nos piden traducirlo a un nuevo idioma objetivo.

Para ello (dada que la opción de Traducción no esta disponible directamente en la transacción Smartforms), accederemos a la transacción SE63 y seleccionaremos la opción de menú Traducción –> Objetos Abap –> Otros textos explicativos.

A continuación, seleccionaremos la opción FS Formularios y estilos –> SSF SAP Smart Form (tal y como vemos en la imagen superior). Finalmente indicaremos el nombre del formulario y el idioma fuente y destino para la traducción (siempre partimos de un idioma base sobre el que realizaremos la traducción al idioma destino).

Al pulsar tratar iremos realizando la traducción de los diferentes textos, pudiendo ver en la parte superior de la imagen el texto en el idioma origen y en la parte inferior los textos traducidos, asociados a cada etiqueta. Nos fijaremos en las etiquetas de cada texto para ver su descripción en Ingles(en este ejemplo), e introducir la correspondiente descripción en Español en la parte inferior, con el correspondiente formato asociado a cada uno de los textos.

Conforme vayamos traduciendo los textos, al activar, estos aparecerán en el formulario cuando el idioma de comunicación con el proveedor (en este caso es un pedido de compra), sea el idioma traducido.

Nota: si estáis trabajando con formularios ADOBE, la opción de traducción si esta disponible en la transacción SFP (donde se programan los formularios), aunque realmente nos llevará igualmente a la transacción SE63 (en la opción FS Formularios y estilos –> PDFB Formularios basados en PDF).

Una vez terminada la revisión de todos los textos, tendremos que realizar el transporte de las traducciones. Como habréis observado, el sistema no nos ha preguntado en ningún momento la orden de transporte en la que incluir.

Para poder realizar el transporte, utilizaremos la transacción SLXT (que ejecuta el report RS_LXE_RECORD_TORDER).

Indicaremos los siguientes valores:

  • (1) Idioma objetivo (destino) que queremos transportar.
  • (2) Descripción que se asociará a la orden de transprote.
  • (3) Tipo de orden: seleccionar la opción Orden de workbench.
  • (4) Fecha de tratamiento: para hacer la selección, fecha en la que hayamos hecho la traducción del formulario.
  • (5) Tipo de objeto: SSF en el caso de formularios Smartform.

Se nos generará la correspondiente orden de transporte donde tendremos incluida toda la traducción de los textos del formulario.

Una vez pasada la orden al sistema destino, podremos utilizar sin problema el formulario en el idioma correspondiente.

La herramienta SLXT esta disponible para transportar traducciones de otros elementos, no solo de los formularios (ver bibliografía, donde se muestra un ejemplo de traducción de la transacción IW32).

¡Feliz lectura!

Bibliografia:

Publicado en Abap, Formacion | Etiquetado , , , , , , | Deja un comentario