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.