Error al modificar Ficha con un "Modificar campo" y Actualización en tabla

Tengo un manejador de evento de un formulario donde, entre otras cosas, realizo un “Modificar campo” de uno de los campos de la ficha del mismo, seguido de un “Interfaz: Guardar la ficha en alta o modificación”. Al llegar a este punto me salta un mensaje de “Error al modificar ficha”.

Usando el depurador descubro que el mensaje que se produce es “Función: ModificarRegistroNoAsegurado. Error 20: La ficha está bloqueada previamente por otro usuario o proceso” y, tras mucho investigar descubro que es porque en ese campo (que es un enlace a Maestro) he colocado una actualización, para que me acumule un valor en un campo de dicho maestro.

¿Hay alguna forma de que pueda forzar la transacción para desbloquear la ficha o bien existe otra manera de guardar los cambios al campo sin usar el código que puse más arriba?

Gracias por adelantado.
Un saludo.

Hola pnogueira.

Tal como ejecutas las operaciones sobre el registro del Formulario no debería haber problema.
Todo lo que se modifica y se guarda desde el Manejador se ejecuta dentro de una sola Transacción incluyendo la Actualización del campo o campos del Maestro.

Mira el vAdmin para comprobar que efectívamente se abre y cierra una sola Transacción.

Tendrás que comprobar el porqué el Maestro está bloqueado antes de modificar el registro del formulario.

Saludos
Paco Satué

Hola Paco.

Con el vAdmin he comprobado que en cuanto ejecuta el comando “Interfaz: Guardar la ficha en alta o modificación” se crea una transacción nueva que se aborta a los 4 segundos, seguida del mensaje “Error al modificar la ficha de: Albaranes de venta” (que es donde estoy ejecutando el manejador de evento.

He comprobado también que si elimino la actualización de tabla del campo que estoy modificando (en este caso VTA_VFAC) el error no ocurre.

Creo que el problema está en que la actualización lo que hace es acumular en un campo de una ficha que es precisamente la que estoy creando, por lo que me parece que lo que ocurre es que me he metido en una situación de pescadilla que se muerde la cola.

Tendré que buscar otra manera de actualizar los datos.

Gracias por tu ayuda.

Un saludo.

Hola pnogueira.

Pues sigo sin ver el problema.
Cuéntanos qué tablas entran en juego y qué Actualizaciones son esas.

Todo lo que hagas dentro de la Transacción es válido siempre y cuando no estén bloquedadas las tabla por otro usuario (que no será el caso) o que hagas algo extraño en los Triggers.

No entiendo eso de: “Creo que el problema está en que la actualización lo que hace es acumular en un campo de una ficha que es precisamente la que estoy creando …”

La Ficha nueva se creará y después del Trigger Interno se ejecuta la Actualización sobre un campo del Maestro que se supone no está bloqueado por otro proceso ¿Dónde está el problema?

Saludos
Paco Satué

Hola Paco.

Te explico:

Todo esto es en vERP. En la ficha de Albarán de Venta hay un manejador de evento donde puedes facturarlo, que normalmente funciona sin problemas.
Lo que yo he hecho ha sido modificar la tabla de ficha de Albaranes y he creado una actualización sobre el campo VTA_FAC, que lo que hace es ir a acumular el campo POT (Portes) de la ficha de albarán en el campo POT de la ficha de factura.

Entonces, en el manejador de evento, cuando llega a la parte en que ejecuta,

[...]    
Modificar campo (VTA_FAC, VTA_FAC_ID)
Interfaz: Guardar la ficha en alta o modificación
[...]

es donde aparece el mensaje de error “Error al modificar la ficha de: Albaranes de venta”

La Factura la crea igualmente sin problemas. El único inconveniente es que sui luego en la ficha de Albarán pulsas “Cancelar” en lugar de “Aceptar” dicho Albarán queda en estado “Sin facturar” y se pierde la trazabilidad con la Factura generada.

Espero haberme explicado bien esta vez. :slight_smile:

Un saludo.

Hola pnogueira.

Bueno, tampoco es que esté muy clara la explicación. Ten en cuenta que yo no uso VERP y así en frio es imposible determinar el error.

Pero estás de suerte. Tenía pendiente revisar las novedades de la 25 y entre ellas estaba instalar VERP 25 y probar el interface de movilidad.

Yendo a tu problema, está clarísimo lo que pasa y acabas de toparte con algo gordo.
Veamos:

  • Tenemos el formulario VTA_ALB_G (Albarán de Venta) con la tabla VTA_ALB_G (Albaranes de Venta).
  • Ejecutamos el manejador VTA_ALB_FAC para facturar el Albarán generando un registro en la tabla VTA_FAC_G (Facturas de Venta).
  • Con el código original de la plantilla VERP todo funciona correctamente.
  • Creamos una Actualización en la tabla VTA_ALB_G sobre el campo enlazado VTA_FAC de la tabla VTA_FAC_G para acumular el valor del campo POR (Portes).
  • Con esto se produce un Error de Modificación de Ficha con el siguiente valor de Retorno:
    Transacción: 65, Estado: Abortada, Título: Modificación ficha VTA_ALB_G: 3, Inicio: 2019-06-03T17:22:50, Fin: 2019-06-03T17:22:54, Operaciones: 0, Retorno: Deshecha por encontrar ficha ocupada

¿Cuál es el problema? Sigamos la ejecución del código con el “estupendo y maravilloso” depurador de Velneo.

En el Manejador VTA_ALB_FAC tenemos:

  • un primer comando Interfaz: Guardar la ficha en alta o modificación
    Transacción: 63, Estado: Finalizada OK, Título: Modificación ficha VTA_ALB_G: 3, Inicio: 2019-06-03T17:21:44, Fin: 2019-06-03T17:21:44, Operaciones: 1, Retorno: Ok
  • un comando Alta de ficha (vta_fac) que crea una Transacción nueva que quedará abierta y bloqueando la Ficha nueva de la tabla VTA_FAC_G.
    Transacción 64, ... Título: Facturar albarán de venta
  • un segundo comando Interfaz: Guardar la ficha en alta o modificación que guardará en el campo VTA_FAC el valor del ID de la nueva Factura creada. Además ejecutará la Actualización sobre la Factura recien creada que todavía sigue bloqueada por la Transacción 64. Por lo tanto, después de 4 segundos se devuelve el error:
    Transacción: 65, Estado: Abortada, Título: Modificación ficha VTA_ALB_G: 3, Inicio: 2019-06-03T17:22:50, Fin: 2019-06-03T17:22:54, Operaciones: 0, Retorno: Deshecha por encontrar ficha ocupada
    Consecuencia, no se guarda el ID de la Factura en el campo VTA_FAC del Albarán.
  • Una vez termina el Manejador, la Transacción 64 se termina con OK y aquí no ha pasado nada. Pues NO, el Albarán queda como NO Facturado. Un desastre, quedando la Base de Datos con la Integridad rota.

¿Por qué se produce el problema?
El comando Interfaz: Guardar la ficha en alta o modificación genera Transacción independiente y no se integra en el proceso del Manejador VTA_ALB_FAC como sí lo hace el comando Alta de ficha. Por esta razón tenemos 3 Transacciones independientes, de las cuales 2 (nº 64 y 65) chocan entre sí.

¿Cuál es la Solución?
Crea un Proceso que dé de Alta la Factura y devuelva la Ficha. Con el comando Ejecutar proceso (que recibe la Ficha del Albarán en memoria) la Transacción del Alta de la factura será independiente y desaparece el problema.

Recuerda que VERP es una Plantilla y hay que mirar con lupa todo el código para adaptarlo a nuestros requerimientos.

Prueba la solución que te propongo y ya nos cuentas.
Si funciona bien, lo pasas a Soporte para que lo incorporen a la nueva Versión ya que es evidente que ese código fallará en cuanto otro añada Actualizaciones como tú has hecho.

Saludos
Paco Satué

1 me gusta

Hola Paco.

Primero, disculpa por las pobres explicaciones, creo que de tanto darle vueltas debí quedar con el cerebro embotado.

A pesar de ello te las has arreglado para localizar y reproducir el problema, eres un crack :+1:

Bueno pues, efectivamente, tu solución ha funcionado a la perfección. (Ya había probado a dividir el proceso en dos manejadores de evento, llamando a uno desde el otro, pero claro, sospecho que así tampoco se estaba liberando la transacción, y no funcionó.) Y la verdad, es que así queda mucho mejor. No me hacía mucha gracia tener código que generase una factura nueva en un manejador de evento de una ficha.

Como siempre, gracias por tu inestimable ayuda. :slight_smile:

Un saludo Paco.

Hola pnogueira.

Perfecto, solucionado. Lo importante es entender el problema y solucionarlo.

Dividir los manejadores no sirve porque siempre se integran en una sola transacción.

Comunica esta solución a Soporte para que la incorporen a VERP.

Saludos
Paco Satué