Machetes Varios

apuntes varios erp cwa logic ( ahora SoftLand Logic ) – sql y veremos que otra cosa

CJ – La modificación “rompe” las Registraciones


Reportado en el grupo cwausers

Es un tema que tengo pendiente hace AÑOS. No es muy sencillo de reproducir.

Última versión en que fue probado : 2.3.6.9

Descripción: Al abrir una registración de Tesorería y luego grabarla, pueden suceder las siguientes cosas:

– La modificación se hace correctamente
– La modificación no se hace
– Modifica algunos item y otros no, dejando el comprobante desbalanceado, o bien imputando
la totalidad de varios items al último.

Explicación:

Cuando se hace la registración original, en la tabla CJRMVI, si el comprobante tiene la opción “recupera items” puede quedar el número de item salteado. Ej.: Tengo el comprobante CANJEV ( para canje de valores ).
Al debe y al haber están todos los bancos
El usuario completa el item 1 y 3 del debe y el 5 del haber. Al grabar, quedan dichos números como nro de item

cjrmvi_codfor cjrmvi_nrofor cjrmvi_nroitm cjrmvi_ctacte cjrmvi_debhab cjrmvi_import
CANJEV 1 1 BANCO1 D 50
CANJEV 1 3 BANCO2 D 30
CANJEV 1 5 BANCO3 H 80

Al abrir el comprobante para hacer la modificación ( supongamos que simplemente cambiar la fecha), el sistema vuelca a la grilla al debe: en la fila 1 y 2, y al haber en la fila 1, o sea que de hacerse bien quedará:
cjrmvi_codfor cjrmvi_nrofor cjrmvi_nroitm cjrmvi_ctacte cjrmvi_debhab cjrmvi_import
CANJEV 1 1 BANCO1 D 50
CANJEV 1 2 BANCO2 D 30
CANJEV 1 1 BANCO3 H 80

El problema es que en cambio de borrar todo y grabar de nuevo hace lo siguiente:

– Toma el GETDATE()
– Por cada item en la grilla:
a)hace un UPDATE de todos los valores( tomando como nro de item el nro de fila de la grilla) y en el campo CJRMVI_FECMOD la fecha capturada en el paso1
b)Si el insert tuvo exito ( con T-SQL se haría tomando viendo si @@ROWCOUNT=1) sigue con la próxima fila, caso contrario hace un INSERT ( con los mismos valores del update)
c) BORRA todos los movimientos donde CJRMVI_FECMOD sea distinto a lo capturado en paso1
d) Finalmente ejecuta el stored procedure CwSpCJProCJRMVIAjustaDif, destinado a arreglar diferencias de redondeo

Por alguna razón que no puedo determinar, en ciertas ocasiones el sistema falla en el paso
b) , “pensando” que el UPDATE tuvo éxito y entonces no hace el INSERT, y es un problema del front end, ya que he probado modificar un comprobante logrando éste efecto, luego reinicio la máquina, lo abro nuevamente, lo modifico y lo hace correctamente. Comparando es STA generado en ambos casos, en el primero no se genera el INSERT Y en el segundo si.

Para colmo de males, el sp CwSpCJProCJRMVIAjustaDif no se fija en montos, y a veces termina de “romper” todo. En el ejemplo, luego de fallar en el update de la fila2 al debe, y luego con el delete borrar el correspondiente a BANCO2, “redondea” asignandole los 80 a BANCO1.

La gente de CWA insiste en que le envíe el backup, no comprendiendo que no es un tema que se pueda reproducir, ya que no depende del estado de la base de datos, sino que es un tema del estado de la aplicación en un momento dado, así que si se quisiera depurar habría que agregar información de debug en éste punto.

Para mí las posibles soluciones serían:

1) Borrar todo e ingresarlo nuevamente
ó
2) hacer el proceso actual pero del lado del servidor, o sea correr por cada fila un stored procedure que de acuerdo a si existan o no registros haga el UPDATE o INSERT correspondiente

diciembre 28, 2006 - Posted by | 1.3 CWA Errores, 1.4 CJ -Tesorería, Cwa Logic

Aún no hay comentarios.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: