Sugerencias sobre numeracion de facturas

[[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

[[fjcg02]]

Si haces el insert del registro en la tabla, ya tienes el nuevo valor generado. Cualquier cancel que hagas posteriormente, no evitará que se tome el nuevo valor ( incrementado).
Lo que necesitas es generar la factura sin utilizar el insert en la tabla.
Yo utilizaría componentes que no sean de BBDD, y cuando vaya a imprimir/guardar, comenzar un transacción, hacer sentencias SQL insert parametrizadas y cerrar la transacción. Si cancelas, no has tocado la BBDD, por lo que el valor del nº de fra. no se habrá incrementado.
Yo en su día utilizaba cacheupdates de los objetos SQL en estos casos, aunque no me acuerdo bien y no tengo el compilador a mano. Realmente lo que hacen es crear registros en local, y al hacer ApplyUpdates ( asociandolo a la impresión/guardado ) realmente inyecta las sentencias sql que hayas definido.

Suerte

[ckaki]

Hola a todos y felíz 2007

Tengo un sistema de facturación y te sugiero lo siguiente.

Como lo han expresado otros no debes asignar el número de la factura hasta que vayas a calcularla o imprimirla. en este caso si el número de la factura es 0 incluso debes permitir que tu aplicación pueda eliminar físicamente el registro, no siendo de esta manera una vez que sea generada, osea que obtenga un consecutivo y después éste aumentará en uno.

Una vez creada la factura no podrás editar los datos y mucho menos eliminarla de la tabla. sin embargo debes permitir que se imprima con el mismo número que adquirió cuantas veces sea necesario y en caso de error cancelarla digamos que pudieras tener un campo lógico en tu tabla por ejemplo "Cancelada" que sería marcado a True cuando intentas eliminar una factura que ya tiene un número consecutivo el cual no volverás a usar.

Espero me hayas entendido

[[kuan-yiu]]

Sobre lo de la numeración de las facturas yo tengo un procedimiento almacenado que cuando lo ejecuto me da el mayor número de factura guardado en la BD y le suma 1.
Para eliminar facturas tengo otros controles que no afectan para nada a este generador.

[[ArdiIIa]]

Yo he utilizado varios y diferentes sistemas y últimamente, concretamente en la última aplicación que estoy haciendo, me he decantado por dejar los generadores para códigos "secundarios o sin importancia" y los contadores de documentos los genero mediante procedimiento que incrementa un campo en una tabla.
Independientemente de como se plantee el asunto de si asignar el número antes de grabar el documento o depués de grabar siempre surgen problemas añadidos.

Por ejemplo: Supongamos una sencilla facturación que está grabando números de factura en el ejercicio del año 2006.... Ha llegado el año 2007 y se supone que los generadores se deberían poner a cero y consecuentemente mediante generadores no podríamos añadir documentos del anterior ejercicio (cosa que en la práctica suele ocurrir). En este caso, yo estoy utilizando una tabla "ejercicios" y cada campo es un contador de documentos actualizable por un procedimiento que es en realidad el que hace toda la faena.. De este modo tengo accesible los contadores del ejercicio actual y los de cualquier otro ejercicio anterior... Luego entonces, cuando inserto un nuevo documento es ese procedimiento descrito anteriormente el que primero se segura que efectivamente haya un ejercicio abierto, segundo hace una búsqueda en otra tabla de "HUECOS" para verificar de que anteriormente no hayamos eliminado algún registro, así podemos recuperar un número perdido de cualquier documento. En el caso de encontrar un número en la tabla HUECOS, devuelve y ese número y es el que se asignará a la factura y en caso contrario, lo que hace es tomar un numero de la tabla de contadores, incrementarlo, y devolver este último número. De este modo no aseguramos que jamás vamos a perder ni un solo número. Este sistema implica que en la tabla afectada (facturas) existe un trigger INSERT para llamar al procedimiento de contadores y otro trigger DELETE para recuperar el múmero perdido e insertarlo en la tabla HUECOS. Este sistema se presume bastante versátil sobre todo cuando tenemos que trabajar con ejercicios.....

En cuando lo de asignar el número al documento antes o después, ambas opciones tienen sus ventajas y por supuesto, sus inconvenientes. Yo aconsejo hacerlo una vez que se graba el documento que es en realidad cuando se accionan los triggers.
Una vez organizado todo el sistema, es el servidor o la DB quien hace prácticamente todo el trabajo sucio, ahorrando muchas líneas de código.

Una de las desventajas que veo a la hora de asignar el número después de grabar es que si por ejemplo el nuevo documento grabado obtiene un número de la tabla HUECOS, este seguramente será un número inferior al último registro grabado y consecuentemente por aquello de los índices, se posicionará en un lugar de la tabla que no se corresponde ordinalmente, perdiendo el usuario la vista de ese registro recién grabado, y en este caso, no funciona ni el GetBookmark ni tampoco será posible localizar ese registro mediante un locate o similar, dado que a priori desconocíamos el número antes de ser grabado... Gran paradoja.
En fin espero haber aportado algún granito y no resultar pesado...

Saludos