os escribo porque estoy teniendo un problema que no consigo resolver, a ver si me podeis echar una mano. Os cuento:
Para ciertos pedidos, tengo que modificar el valor de un campo de la posición de un pedido, el campo ZTERM (paym. terms). Esta modicicación puede afectar a uno o varios items.
El código con toda la lógica lo había puesto dentro de la ampliación MV45AFZZ -> USEREXIT_SAVE_DOCUMENT_PREPARE, y no ha funcionado.
Tambien he probado a añadir el código en la ampliación MV45AFZZ -> USEREXIT_MOVE_FIELD_TO_VBKD, pero tampoco no ha tenido exito.
No sé si es porqué me falta algo en él código o que se debe hacer en otro sitio. Os pongo ejemplos de código usados en la ampliación USEREXIT_SAVE_DOCUMENT_PREPARE:
— EJEMPLO 1 —
READ TABLE XVBKD WITH KEY vbeln = xvbap-vbeln posnr = xvbap-posnr.
IF sy-subrc EQ 0.
XVBKD-ZTERM = 'NUEVO_VALOR'.
XVBKD-UPDKZ = 'U'.
MODIFY XVBKD INDEX sy-index.
ENDIF.
FIELD-SYMBOLS: <fs_xvbkd> LIKE xvbkd.
DATA: ls_yvbkd LIKE yvbkd.
IF t180-trtyp = 'V'.
READ TABLE XVBKD ASSIGNING <fs_xvbkd> WITH KEY vbeln = xvbap-vbeln posnr = xvbap-posnr.
* Save unchanged version of XVBKD to YVBKD
ls_yvbkd = <fs_xvbkd>.
APPEND ls_yvbkd TO yvbkd.
<fs_xvbkd>-ZTERM = 'NUEVO_VALOR'.
<fs_xvbkd>-UPDKZ = 'U'.
upd_vbkd = 'U'.
ENDIF.
Por último, también he intentando modificar a pelo (como último recurso) la estructura en la ampliación MV45AFZZ -> USEREXIT_MOVE_FIELD_TO_VBKD, pero sin éxito. Os pongo las formas que he usado::
Es más, en el caso de la ampliación USEREXIT_MOVE_FIELD_TO_VBKD, al poner una de las dos formas descritas ocurre que entra en bucle infinito y tengo que cerrar el modo…no sé porqué será.
Efectivamente, lo hace todo OK, asigna el nuevo valor a vbkd-zterm y termina la ejecución. A continuación, si vuelves a consultar el pedido (va02 o va03) aparece el antiguo valor en ZTERM, no el nuevo valor asignado. También miro en la tabla vbkd y tampoco se ha modificado.
No sé si tiene algo que ver con el zterm guardado en la posicion 000000 dentro de la tabla xvkd (es como el zterm guardado en la cabecera)…que de alguna manera este afectando…esta posicion no la actualizo. Solo actualizo las posiciones de los items (desde la posicion 000010 en adelante).
¿no has podido seguir el debug más allá de tu exit, a ver donde se vuelve a modificar?¿y las 9 posiciones anteriores? o quizá la condición de pago de área de ventas sea prioritaria. ¿necesitas el cambio de la condición de pago en el documento FI?
Resulta que he encontrado casos en los que el código funciona OK y otros donde el código falla. Así por lo alto, la diferencia que he encontrado es relacionada a una propiedad del customer (comprador/vendedor) asociado al pedido. Pongo los dos casos:
Crear pedido usando customer con campo KNVV-ZTERM informado: Al elegir a este customer durante la creación del pedido, de forma automatica se asigna el valor de KNVV-ZTERM en la condición de pago contenida en la cabecera del pedido (posicion 000000 de xvbkd). Una vez creado el pedido, no consigo actualizar el valor vbkd-zterm (xvbkd-zterm) de cualquier posición del pedido.
Crear pedido usando customer con campo KNVV-ZTERM no informado: Al elegir a este customer durante la creación del pedido, la condición de pago de la cabecera del pedido (posicion 000000 de xvbkd) no está informada. Una vez creado el pedido, consigo actualizar el valor vbkd-zterm (xvbkd-zterm) de cualquier posición del pedido.
Estos dos casos los he visto justo antes de salir del trabajo.
Seguiré investigando para verificar que siempre se cumple los casos expuestos en esta respuesta, a fin de acotar el origen del problema. También intentaré seguir el debug como dices @Salco para encontrar en que momento se vuelve a modificar el valor.
Lo que has dicho de las 9 posiciones anteriores no sé exactamente a que te refieres…he visto poco acerca de SD.
Necesito hacer la actualización de la condición de pago en determinadas posiciones de un pedido de tipo OR (creado a partir de la va01) y de otro pedido de tipo Z.
Si por algún motivo la condición de pago del pedido (la que aparece con la posicion 000000 dentro de la xbkd) es prioritaria sobre las condiciones de pago de las posiciones del pedido…hay alguna forma de omitir esta prioridad, eliminar dicha prioridad o cambiarla de alguna forma (por customizing por ejemplo)?
Pues parece que después de la exit donde modificas la condición de pago, el proceso va a consultar el maestro de deudores y toma el valor de allí. No se mucho de SD, quizá por customizing se podría solucionar y si no encontrar una exit posterior a la consulta del maestro. Quizá alguien de @Ventas nos pueda decir algo.
En mi empresa tuvimos que cambiar una vez la condicion de pago y tuvimos que hacerlo uno a uno manualmente. Los consultores nos dijeron que para ciertos parametros SAP no permite modificaciones masivas.
Puede que hayan sido un poco vagos.
De todas formas, tal vez tendrias que revisar la condicion credicia de los clientes. Si estan excedidos de credito puede que no te deje modificar nada del pedido.
Saludos
@lulina88 la condición de pago se puede cambiar masivamente con la tx. MASS por ejemplo, pero creo que @rafbercar no quiere cambiar el maestro, sino que para determinados pedidos use una condición u otra.
En realidad el código funciona correctamente…explico el flujo encontrado debugeando @salco:
El problema venía de una ampliación Z de la user-exit USEREXIT_PRICING_PREPARE_TKOMP, localizada el report MV45AFZZ. En ella se recuperaba el ZTERM del knvv (según kunnr, vkorg, vtweg y spart) y se asignaba a TKOMP-ZTERM.
Más adelante, según he visto debugeando, el estandar (Report SAPFV45K -> FORM: VBKD_BEARBEITEN_ZTERM) chequea lo siguiente:
IF NOT US_ZTERM IS INITIAL.
IF US_ZTERM NE VBKD-ZTERM OR
US_VALDT NE VBKD-VALDT OR
US_VALTG NE VBKD-VALTG.
VBKD-ZTERM = US_ZTERM.
VBKD-VALDT = US_VALDT.
VBKD-VALTG = US_VALTG.
.
..
....
Siendo US_ZTERM = TKOMP-ZTERM.
Por consiguiente, si el knvv-zterm <> ‘NUEVO_VALOR’, no actualiza la condición de pago del item del pedido.
Por ello, en la ampliación USEREXIT_PRICING_PREPARE_TKOMP obligo siempre a que
TKOMP-ZTERM = ‘NUEVO_VALOR’ y de esta forma el estandar acepta el cambio, :).
Bueno, les doy las gracias por toda la ayuda prestada!! Si tienen cualquier duda aquí estamos, :D.