Truco 126. Limitar las agrupaciones y roles disponibles en los gestión de los BP.

Una vez vamos profundizando en el uso de S/4HANA, más en concreto, en la gestión de los Business Partners, echamos de menos alguna funcionalidad, como, por ejemplo, el que, al crear un BP dentro de una agrupación determinada, tengamos un mecanismo sencillo para poder limitar los roles (funciones de interlocutor), que están disponibles en cada uno de las agrupaciones.

Por ejemplo, estamos creando clientes que son direcciones de entrega de mercancía, para los que hemos previsto un Agrupación determinada (para determinar su rango de números y su grupo de cuentas de cliente), pero al abrir el desplegable de roles, nos aparecen todos los que se han habilitado como activos en el sistema, incluyendo grupos de roles. Esto es una fuente de posibles problemas y errores, pudiendo utilizar el usuario las funciones de interlocutor (roles) que no estaban previstos.

Otro tema que nos puede interesar controlar es las agrupaciones que estan disponibles según el tipo de interlocutor que estemos creando. Por ejemplo, si creamos un interlocutor del tipo Persona, que no nos aparezcan las agrupaciones definidas para crear los clientes o proveedores, y solo aparezca, por ejemplo, las de persona de contacto.

No tenemos una opción de parametrización para controlar estos aspectos, pero si podemos gestionarlo utilizando varias BADIS que Sap pone a nuestra disposición (desde la versión SAP S/4HANA On Premise 1610 y superiores):

BUPA_ROLE_INFLUENCE: para intervenir en las funciones de interlocutor (Roles), que se pueden utilizar según la agrupación. Se puede implementar aplicando la nota 2571755 – Provision to influence Business Partner roles in Business Partner transaction, si no lo teneis disponible en vuestro sistema.
BUPA_NUMBER_GROUP: para intervenir en las agrupaciones disponibles al crear un BP, según el tipo seleccionado (Persona, Organización o Grupo).

En los blogs de SAP, Andi_M, nos explica paso por paso un ejemplo de implementación de las BADIs para conseguir este objetivo. Veamos un poco más en detalle los pasos para su implementación.

BUPA_ROLE_INFLUENCE

La idea es crear una tabla Z donde indicaremos, por cada Agrupación, los roles o funciones IC que tenemos disponibles en el momento de creación de un nuevo Business Partner.

La tabla tendrá su dialogo de actualización y podremos mantener las entradas en ella con la SM30:

Una vez creada la tabla, realizaremos la implementación de la BAdI BUPA_ROLE_INFLUENCE con la transacción SE19. Un ejemplo de código en el metodo IF_EX_BUPA_ROLE_INFLUENCE~INFLUENCE_ROLES es el siguiente:

  METHOD if_ex_bupa_role_influence~influence_roles.

    DATA: lt_role    TYPE TABLE OF zbp_group_role,
          ls_values  TYPE LINE OF bus_screen-dropdown_values,
          lv_sytabix TYPE sy-tabix.

    CHECK NOT ct_possible_roles IS INITIAL.

    SELECT * FROM zbp_group_role INTO TABLE lt_role WHERE bu_group = cv_number_group.

    IF NOT lt_role IS INITIAL.
      LOOP AT ct_possible_roles INTO ls_values.
        lv_sytabix = sy-tabix.
        READ TABLE lt_role WITH KEY role = ls_values-key TRANSPORTING NO FIELDS.
        IF sy-subrc NE 0.
          DELETE ct_possible_roles INDEX lv_sytabix.
        ELSE.
          lv_sytabix = lv_sytabix + 1.
        ENDIF.
      ENDLOOP.
    ENDIF.

* set default role (first in table)
    SORT ct_possible_roles BY key.
    READ TABLE ct_possible_roles INDEX 1 INTO cv_default_role.

  ENDMETHOD.

Al realizar la creación del BP, solo se nos mostrarán los roles permitidos por la agrupación. Ademas, esta configuración nos permite definir un rol por defecto.

De una forma sencilla, hemos conseguido que la tarea de creación de los BPs sea más sencilla y con menos posiblidades de errores. Y con una tabla de configuración que se puede ajustar en cualquier momento en productivo.

BUPA_NUMBER_GROUP

Partiremos igualmente de una tabla donde indicaremos, por tipo de interlocutor (Persona, Organización o Grupo), las agrupaciones que estan disponibles en el momento de crear el BP.

La tabla tendrá su dialogo de actualización para realizar el mantenimiento de los valores con la SM30:

A continuación, realizaremos la implementación dela BADI BUPA_NUMBER_GROUP con la transacción SE19, definiendo el método IF_EX_BUPA_NUMBER_GROUP~VALID_NUMBER_GROUP. Un ejemplo de implementación del código es el siguiente:

  METHOD if_ex_bupa_number_group~valid_number_group.

    DATA: lt_group     TYPE TABLE OF zbp_type_group,
          lv_type      TYPE bu_type,
          ls_values    TYPE LINE OF bus_screen-dropdown_values,
          lv_sytabix   TYPE sy-tabix.

    lv_type = iv_request->gs_navigation-bupa-creation_type.

    SELECT * FROM zbp_type_group INTO TABLE lt_group WHERE type = lv_type.

    LOOP AT et_dropdown_values INTO ls_values.
      lv_sytabix = sy-tabix.
      READ TABLE lt_group WITH KEY bu_group = ls_values-key TRANSPORTING NO FIELDS.
      IF sy-subrc NE 0.
        DELETE et_dropdown_values INDEX lv_sytabix.
      ELSE.
        lv_sytabix = lv_sytabix + 1.
      ENDIF.
    ENDLOOP.

  ENDMETHOD.

Al crear los BPs, y seleccionar el tipo de interlocutor que estamos creando, tendremos restringidas las agrupaciones que podemos elegir según la tipología elegida.