Controlador Fiscal Hasar y Tablas nativas de VFP

[Gustavo Rojo]

Hola Estimados! espero anden muy bien!

Necesitaría una mano con el siguiente problema:

Tengo un sistema de facturación que administra varios controladores fiscales (son 3 puntos de venta), el problema que detecte es que en la base de datos se me están guardando mal algunos tickets (el porcentaje es bajo pero sumamente sensible, de 8500 ticket en el ultimo mes, veo que 23, están mal guardados). Por ejemplo, se imprime correctamente el ticket, pero se guarda solo la cabecera del ticket y con los valores en cero y el detalle no se guardo.

Uso vistas remotas y sesiones privadas en los formularios de ventas.

El flujo de trabajo es el siguiente:

1_ Desde un formulario genero el ticket, tabla ventas y detalle_ventas

2_ Una vez finalizada la venta, mando a imprimir el ticket, 

3_ Si se imprime correctamente, mando a guardar las tablas. 

Esto funciona correctamente salvo en estos casos que detecte.... que son aleatorios...

Que puedo estar haciendo mal?

[Daniel Sánchez]

La pregunta sería, estas trabajando con tablas locales (dbf) o contenedor de tablas dbf (dbc) o algún motor de base de datos sql como mysql, sqlserver, firebird u otro. En todo caso mira si algún evento hace que el grabar no siga el flujo normal de tu programa, manejas control de errores al almacenar tus datos, tal vez indica un error pero como no lo controlas sigue a la siguiente línea sin haber grabado el dato deseado, ahora otra forma para que tengas la seguridad de que todo lo que deseas se grabe es usar transacciones, esto permite si uno de los procesos de grabación en alguna de las tablas no se realiza, deshace todo lo realizado dentro del bloque de la transacción, o hace todo o no hace nada, pero siempre manejando el control de errores para saber si todo salio ok.

Saludos

--

Daniel Sánchez Escobar
Investigación y Desarrollo
Reset Software & Sistemas
Móvil +051-949398047 RPM #948615385
Trujillo - Perú

P  Sugerimos no imprimir este e-mail a menos que sea absolutamente necesario. Protejamos el medio ambiente.

[Gustavo Rojo]

Hola Daniel, muchas gracias por tus comentarios.

Te cuento, uso contenedor de tablas DBC con vistas remotas. Al grabar uso transacciones... el problema que tengo es aleatorio, eso es lo mas difícil de detectar... de un total aproximado de 9000 facturas en el mes, detecto que 20, se grabaron mal (se grabo solo la cabecera de la factura con sus valores en 0 y no se guardo el detalle), pero se imprimió correctamente (o sea, al momento de imprimir estaban todos los datos consistentes), repaso el flujo y no veo nada inapropiado... pero evidentemente en algún lado le estoy errando.

Saludos

--

Gustavo Rojo| Scrum Master & Sr. Analyst
La Plata (1900), Buenos Aires, Argentina
Office: +54.9.221.5374343 
Skype: rojo.gustavo

gusta...@gmail.com

[Daniel Sánchez]

En todo caso después de grabar los datos realiza una consulta para ver si dichos items se encuentran en la tabla, podrías hacer una consulta posterior de grabar e imprimir para que vea si los datos o items es el mismo en tu cursor como en la tabla, un select count(*) from tablaitems where miID=nMiID donde miID es el número de secuencia o autoincremental que debo suponer relaciona tu tabla cabecera con el detalle, si no es así cambia por los campos correspondientes que los relacionan, si el conteo de item no es igual al del cursor local significa que no se grabo los datos correctamente, te pongo un count(*) o podría ser sum(valorventa) para determinar si la suma o la cantidad corresponde a tus datos en tu cursor, esto lo hace rápido así que no deberías perder performance al realizar dicha validación, si no es igual puedes volver a intentar grabar los datos, y en una tabla llevar el registro de dicha falla y reintento de grabar la información. 

No te olvides la verificación de tu tableupdate para ver si no devuelve false al realizar la grabación en la tabla correspondiente.

Saludos

[Gustavo Rojo]

Daniel, te paso el codigo que empleo para grabar:

SET MULTILOCKS ON

BEGIN TRANSACTION

DO WHILE .t.

IF TABLEUPDATE(.T.,.T.,"v_ventas") .and. TABLEUPDATE(.T.,.T.,"v_ventas_detalle") .and.           TABLEUPDATE(.T.,.T.,"v_articulos_stock")

END TRANSACTION

EXIT 

 ELSE

Reintento=MESSAGEBOX("Error al grabar venta" + CHR(13) + "Reintenta grabar?",36,"Atencion")

IF reintento = 6

LOOP 

 ELSE 

ROLLBACK

=TABLEREVERT(.t.,"v_ventas")

=TABLEREVERT(.t.,"v_ventas_detalle")

=TABLEREVERT(.t.,"v_articulos_stock")

EXIT 

ENDIF 

ENDIF

ENDDO 

Si te parece que este codigo puede tener alguna falla por favor hazmelo saber.

Saludos

[Daniel Sánchez]

Me parece que esta indicando o haciendo un uso incorrecto de tableupdate

TABLEUPDATE( [nRows [, lForce]] [, cTableAlias | nWorkArea] [, cErrorArray] )

y tu

TABLEUPDATE(.T.,.T.,"v_ventas")

y me parece que debería ser

TABLEUPDATE(.T.,"v_ventas")

ya que el primer parámetro es un numero de 0 a 2 o .t. o .f. no son dos parámetros si no solo uno de los dos y el segundo parámetro es la referencia de la tabla, ahora otra cosa una vez que te da error deberías mostrar que error ocurrió para eso debes hacer uso de aerror que es un array que te devuelve los datos del error ocurrido y por último te recomiendo que cada tableupdate lo realices por separado, así si una de las tablas te da error ya sabes cual es, porque así solo sabes que hubo un problema pero no sabes en que tabla, son más lineas pero es más legible y fácil de mantener, otra cosa que veo que muestras un mensaje que espera una respuesta dentro de una transacción, si el usuario se fue al baño o a tomar un cafe puedes dejar a los demas usuarios bloqueados hasta que de aceptar, eso no debe ocurrir, así que no se debe poner mensajes que dependan de los usuarios en medio de una transacción, en todo caso tu método solo debe grabar si no pudo devuelve falso y recien determinas que hacer.

Saludos

[Gustavo Rojo]

Muchas gracias Daniel por tus observaciones, las voy a poner en practica y te cuento como me fue.

Saludos!

[Jose Otoniel Melendez]

Revisa q use conexión de red  de cableada ya que la inalámbrica suele dar esa clase errores en la pérdida de paquetes
Este problema me sucedió en 2005 coloque verificadores de data pero la sitúacion empeoró era que el terminal estaba con inalámbrica

[Gustavo Rojo]

Hola José!

Gracias por el dato. En este caso es una red cableada.

Saludos