Sugerencias sobre numeracion de facturas

[JoanKa]

A ver amigos parece que el termino "cancelar" nos esta dando problemas de interpretacion, me estoy refiriendo al temino de cancelar una factura, es que cuando por ejemplo un cliente esta comprando y esta en la factura 10450 y esta comprando y justo en ese momento de va la corriente electrica o el cliente se arrepiente por que lo que tiene no le alcanza para comprar es alli donde presiono el BOTON DE CANCELAR., entonces la proxima vez que yo presione el BOTON de NUEVA FACTURA voy a tener la factura 10451, y eso es lo que me esta pasando en estos momentos. y CREO QUE NO ES CORRECTO A NIVEL MUNDIAL, porque no me debe dar la 10451 sino la 10450.

Me parece que ahora esta mejor.

En delphi como se puede hacer esto ???

Gracias y espero haberme explicado mejor.

[ContraVeneno]

Entonces el problema supongo esta en que estas asigando el número de factura antes de tenerla lista.

Mi sugerencia es que no le asignes número de factura hasta que no este completa la transacción.

[JoanKa]

Ahora nos entendemos mejor. Pero en codigo como podria realizarlo, lo que pasa es que quiero que todo este en orden, y es como debe ser por alli leyendo me dicen que tengo que ponerlo en el Beforepost de los dataset, pero previo a esto me parece que tenqo que buscar el ultimo registro.... en codigo como puedo hacer esto.

Gracias

[[egostar]]

Pues mas que código (creo que lo estas ya haciendo) tu problema es de concepto, si tienes un botón de cancelar deberías de usar el botón de imprimir para cerrar el folio.

Yo haria lo siguiente:

Si presiono el botón de CANCELAR hago un Rollback y si presiono el botón ACEPTAR hago un COMMIT.

Saludos.

[[AzidRain]]

Aqui tienes otra idea depende de como tengas configurada la impresión, si la impresora (y sus facturas) están conectadas solo a esa PC:

* Iniciar la transacción
* Obtener el siguiente de numero de factura que le corresponda (solo como referencia ya que se supone que es el mismo folio que esta en ese momento en la impresora listo para imprimir)
* Hacer la transacción
* Imprimir la factura
* ¿Se imprimió correctamente? (Si) (No) (pudo haberse atascado, roto, etc.)
Si si se imprimió (ahora si) guardar el folio a la BD
Si no se imprimió bien, saltar al siguiente folio y reintentar la impresión

[Combat-F2D]

Si si se imprimió (ahora si) guardar el folio a la BD
Si no se imprimió bien, saltar al siguiente folio y reintentar la impresión

¿y que pasaria si no imprimo porque no quiero hacerlo?, bine porque llegado el momento necesito realizar un proceso masivo de facturacion y por algun motivo no deseo sacarlas a papel pues por ejemplo porque en ese momento no dispongo de él?

yo sugiero un contador de facturas, no un generador ni similar para evitar los posibles huecos en la correlatividad de las mismas; además este contador estando ubicado en otra tabla podria manejarse y variar según conveniencia.

la experiencia me dice que los clientes, por muy correcto, legal, etc, prefieren no tener anuladas ni generar facturas de abono salvo ultimo recurso, y al fin son los que pagan y exigen.

la forma de generar esos numeros elementalmente estarian dentro de una misma y unica transacion, tal y como se indica

vamos, no deja de ser mas que un idea más

[[Lepe]]

Yo antes de nada, sugiero que no se utilice el número de factura como clave principal de la tabla (que sería lo lógico). Precisamente por todo lo comentado aquí.

Creamos un Store Procedure, que dada la clave primaria de una factura, nos devuelva el nº correlativo de dicha factura (o inserte el valor en la tabla factura). Sólo llamamos a este procedimiento cuando realmente estamos seguro de grabar la factura.

El correlativo, puede ser un generador. En caso de fallos, siempre se puede establecer un generador a un nº determinado.

Saludos