Saltar al contenido

ME_PROCESS_PO_CUST ~ PROCESS_ITEM

Un Usuario hizo la siguiente pregunta

Hola amigos.

Badi ME_PROCESS_PO_CUST se utiliza para salidas de usuario estándar para transacciones ME21N, ME22n y ME23n

Estoy usando el método PROCESS_ITEM para verificar la condición a nivel de artículo y luego actualizar fieald en la condición (KWERT) y luego quiero actualizar la condición.

El código en el método process_item es:

detalles: lpo_mepoitem mepoitem type

, ls_condition TYPE komv

, lt_conditions escriba MMPUR_TKOMV.

ls_mepoitem = im_item-> get_data ().

im_item-> get_conditions (IMPORTAR EX_CONDITIONS = lt_conditions).

BUCLE EN lt_conditions EN ls_condition DONDE kschl = «PB00».

ls_condition-kwert = «88.8»

MODIFICAR lt_conditions de ls_condition.

TERMINARA SI.

ENDLOOP.

im_item-> set_conditions (lt_conditions).

.

El código se compila y se puede ejecutar, pero el resultado es que el marco estándar de SAP comienza en un ciclo sin fin y sale después de varios ciclos.

Si elimino la declaración im_item-> set_conditions, entonces no hay bucle sin fin, por lo que la falla está en el modo set_conditions. (Que es un método estándar). También recibo este mensaje de error del sistema y luego parece imposible actualizar el campo KWERT.

¿Alguien puede asegurarme que este es el caso o alguien puede ayudarme a hacer este trabajo (cambie el campo KWERT en las condiciones en las que el PO está procesando los artículos)? ?

Aquí están los mensajes de error del sistema.

No se aceptan datos del complemento empresarial ME_PROCESS_PO_CUST

Mensaje no. MEPO151

Diagnóstico

Se produjo un bucle sin fin mientras se procesaba el complemento empresarial ME_PROCESS_PO_CUST. El sistema terminó el procesamiento.

Procedimiento

Comuníquese con el administrador de su sistema.

Procedimiento de administración del sistema

Compruebe si la implementación del complemento empresarial ME_PROCESS_PO_CUST cambia los campos estándar.

Normalmente no se permiten cambios en los campos estándar que forman parte de la estructura Incluir MEPOITEM_TECH y / o MEPOSCHEDULE_TECH. Además, los valores de campo que no se pueden cambiar mediante la configuración del campo en las transacciones Enjoy no se pueden cambiar en el BAdI. Corrija la implementación en consecuencia.

5 respuestas

  • Ex miembro

    Hola ,

    Usa el siguiente código

    DETALLES: tipo de etiqueta LV_PO_HEAD_REF a IF_PURCHASE_ORDER_MM,

    Etiqueta de tipo CL_PO a CL_PO_HEADER_HANDLE_MM.

    LV_PO_HEAD_REF = IM_ITEM-> GET_HEADER ().

    * Empiece a comprobar los encabezados

    CL_PO? = LV_PO_HEAD_REF.

    si CL_PO-> MY_RECHECK_QUEUE no está inicializado.

    borre CL_PO-> MY_RECHECK_QUEUE.

    terminara si.

  • Ex miembro

    Hola

    La respuesta es una suposición pura.

    Por favor, consulte la nota de OSS

    Nota 803749 – ME_PROCESS_PO_CUST Business Plugin: bucle sin fin

    Por favor, tome una opinión de Basis / SAP, antes de aplicar la nota OSS

    Sobre

    Madhan D.

  • Ex miembro

    ALTO,

    Va a un ciclo sin fin debido a una línea de pedido ilimitada, solo tiene dos líneas que podrían resolver su problema

    DETALLES: lv_bnfpoTYPE banfpo.

    IMPORTA lv_bnfpo A lv_bnfpo DESDE EL ID DE MEMORIA ‘ZHDR’.

    **> Si la línea de pedido cambia (la línea de pedido cambia de pista)

    SI lv_bnfpo <> lv_items-bnfpo

    su código de condiciones establecido.

    ID MENTAL GRATIS ‘ZHDR’.

    lv_bnfpo = lv_items-bnfpo. «Lv_items es una tabla procedente del modo get_data

    EXPORTA lv_bnfpo DESDE lv_bnfpo AL ID DE MEMORIA ‘ZHDR’.

    terminara si.

    Gracias,

    Ruchi

  • Ex miembro

    Hola,

    Recibo el mismo error y también quiero usar set_conditions. ¿Todavía tienes una solución? ¿Podrías compartir conmigo? Gracias.

    Sanny

  • Agregue el siguiente código al final del método. Primero se hizo referencia a ABAPblog.com – Bucle sin fin en BADI ME_PROCESS_PO_CUST

    DETALLES: f_item TYPE REF TO if_purchase_order_item_mm.
    SÍMBOLOS DE PASO: TIPO ekko.

    DETALLES: f_mepoitem TYPE mepoitem.
    DETALLES: fo_header TIPO REF TO if_purchase_order_mm.
    DETALLES: f_checkheader TYPE mepoheader.
    DETALLES: f_checkheader_curr TYPE mepoheader.
    DETALLES: TIPO cadena f_ekkotxt.

    DETALLES: COMIENZO DE fs_condcheck,
    establecer TIPO c,
    ebelp TIPO ekpo-ebelp,
    END fs_condcheck.

    DETALLES: ft_condcheck PUEDO ESTÁNDAR TABLA fs_condcheck.

    NO COMPRUEBE f_item INICIATIVA.

    f_mepoitem = f_item-> get_data ().

    f_ekkotxt = «(SAPLMEPO) EKKO». «usaremos ekko de me21n
    DETALLES (f_ekkotxt) IR . «¡¡¡No hagas cambios en ese FS !!!
    MÁ sy-subrc EQ 0.
    «Solo realizamos cambios en una nueva orden de compra y el solicitante ‘TESTONE’
    «por supuesto que deberías poner tu propio chodding aquí
    SI -ebeln + 0 (2) NE ’45’ Y f_mepoitem-afnam EQ ‘TESTONE’.
    «estamos importando datos de la memoria
    IMPORTAR ft_condcheck = ft_condcheck
    f_checkheader = f_checkheader
    De ID DE MEMORIA ‘CONDADJUST’.

    «obtener objeto de encabezado
    fo_header = f_item-> get_header ().
    fo_header = f_item-> get_header ().

    «obtener datos de encabezado actuales
    f_checkheader_curr = fo_header-> get_data ().

    «compare el encabezado actual con el de la memoria
    IF f_checkheader_curr <> f_checkheader.
    «si es diferente, tenemos una nueva orden de compra
    ACTUALIZAR ft_condcheck[].
    f_checkheader = f_checkheader_curr.
    «borrar cond wa y configurar ebelp
    BORRAR fs_condcheck.
    fs_condcheck-ebelp = f_mepoitem-ebelp.
    DEMÁS.
    «estamos en el mismo PO que antes, así que verifiquemos si ya lo tenemos
    «detalles de la situación actual en nuestra lista de verificación
    LEA LA TABLA ft_condcheck CON MAIN ebelp = f_mepoitem-ebelp INTs fs_condcheck.
    MÁ sy-subrc NE 0.
    «si no, comprobaremos wa y configuraremos ebelp
    BORRAR fs_condcheck.
    fs_condcheck-ebelp = f_mepoitem-ebelp.
    TERMINARA SI.
    TERMINARA SI.

    «si la condición se solucionó previamente, no hacemos nada
    Si fs_condcheck-set INICIATIVA.
    DETALLES: ft_conditions TYPE mmpur_tkomv.
    DETALLES: f_cond_changed TIPO c.
    SISTEMAS DE CAMPO: TIPO komv.
    «Borrar condición de cambio de bandera
    BORRAR f_cond_cambiado.
    «obtener condición para el artículo
    f_item-> get_conditions (IMPORTAR ex_conditions = ft_conditions[] ).

    «nuestra manipulación de las condiciones (haz tu codificación aquí)
    LOOP AT ft_conditions ASIGNACIÓN .
    SI -kschl NE ‘PB00’ Y
    -kschl NE ‘PBXX’ Y
    NO -KBET INICIATIVA.

    CLARO -kbetr.
    -kmprs = «X».
    «establece que hemos cambiado
    f_cond_changed = ‘X’.
    TERMINARA SI.
    ENDLOOP.

    «comprobar si cambiamos algo
    SI NO f_cond_changed INICIATIVA.
    «si es así, establecemos condiciones
    f_item-> set_conditions (EXPORTAR im_conditions = ft_conditions[] ).
    «Complete los datos de verificación y establezca las condiciones para este ebelp
    «ya guardado
    fs_condcheck-set = «X».
    «exportar datos a la memoria para que podamos leerlos en la siguiente llamada process_item
    APPEND fs_condcheck TO ft_condcheck[].
    EXPORTACIONES ft_condcheck = ft_condcheck
    f_checkheader = f_checkheader
    MEMORIA DE ID DE CHUN ‘CONDADJUST’.
    TERMINARA SI.
    DEMÁS.
    DETALLES: fo_order TIPO REF TO cl_po_header_handle_mm.
    DETALLES: fo_model TYPE REF TO if_model_mm.
    «encabezado de transmisión
    fo_order? = fo_header.
    «modelo de elemento de reparto
    fo_model? = f_item.

    «compruebe si un artículo todavía está en la cola para volver a comprobarlo
    LEA LA TABLA fo_order-> my_recheck_queue CON MAIN MODEL = fo_model TRANSPORTE SIN CAMPOS.
    MÁ sy-subrc NE 0.
    «si no, podemos eliminar las entradas de la tabla para que podamos comprobar
    «en el siguiente cambio de elemento
    BORRAR ft_condcheck DONDE está ebelp = f_mepoitem-ebelp.
    «exportar datos a la memoria sin conexión previamente modificada
    EXPORTACIONES ft_condcheck = ft_condcheck
    f_checkheader = f_checkheader
    MEMORIA DE ID DE CHUN ‘CONDADJUST’.
    TERMINARA SI.
    TERMINARA SI.
    TERMINARA SI.
    TERMINARA SI.