Sugerencias sobre numeracion de facturas

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

[[Lepe]]

Empezado por ArdiIIa

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.

Estoy de acuerdo con esa filosofía, al menos en tablas planas, usando tablas sql, hay otras alternativas como las ya comentadas.

Empezado por ArdiIIa

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

¿Por qué?, Dado que los generadores se crean e incrementan a través de su nombre (un string), se puede construir generadores cada año. Un programa con 100 tablas tendrá (normalmente) 100 generadores para sus claves primarias, para que ocurra lo mismo en facturas, deberían pasar 100 años usando el programa.

Empezado por ArdiIIa

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

Como ya se ha dicho, no puede existir huecos en la numeración de facturas. Por otro lado, e intentando encontrar sentido a lo que dices, tu método podría servir para reutilizar el último número de factura que ha sido borrado, pero, en este caso, ¿no resulta más eficiente grabar sólo cuando se ha aceptado la factura?. Si el cliente pide que se pueda borrar una factura, se le dice claramente: "lo que me pides es ilegal y no voy a hacerlo", (señores, no se está jugando a la PlayStation )

Empezado por ArdiIIa

consecuentemente por aquello de los índices, se posicionará en un lugar de la tabla que no se corresponde ordinalmente,

¿Pero de qué hablamos? En tablas de escritorio sí hay diferencia entre llamar al método Append o al método Insert, respecto a la posición física del registro en la BBDD. En tablas sql, (como se habla en este hilo) no hay diferencia, ya que siempre usaremos un ORDER BY.

Empezado por ArdiIIa

perdiendo el usuario la vista de ese registro recién grabado

Ya no sé si hablamos de aislamiento de las transacciones, de inserciones o de qué, lo siento .

Empezado por ArdiIIa

En fin espero haber aportado algún granito y no resultar pesado...

Eso mismo espero yo Saludos

[[ArdiIIa]]

Veamos si poco a poco vamos aclarándonos... esto promete.

Empezado por Lepe

¿Por qué?, Dado que los generadores se crean e incrementan a través de su nombre (un string), se puede construir generadores cada año. Un programa con 100 tablas tendrá (normalmente) 100 generadores para sus claves primarias, para que ocurra lo mismo en facturas, deberían pasar 100 años usando el programa.

Supongo que cuando estamos hablando de generadores, nos estamos refiriendo a los internos y que se actualizan de este modo:

Código SQL [-]
NEW.CODIGO = Gen_Id(AUX_TIPO_SERVICIO,1);

Si es así, no entiendo muy bien tu planteamiento de construir generadores cada año.

Empezado por Lepe

Como ya se ha dicho, no puede existir huecos en la numeración de facturas. Por otro lado, e intentando encontrar sentido a lo que dices, tu método podría servir para reutilizar el último número de factura que ha sido borrado, pero, en este caso, ¿no resulta más eficiente grabar sólo cuando se ha aceptado la factura?. Si el cliente pide que se pueda borrar una factura, se le dice claramente: "lo que me pides es ilegal y no voy a hacerlo", (señores, no se está jugando a la PlayStation )

Aunque somos conscientes de lo que hablamos, y en este caso nos referimos a facturas, yo esto lo extiendo más... (Albaránes, Notas de Entrega, etc) luego dicho esto, no conozco ninguna aplicación que limite el borrado de registros de cualquier tipo de documentos, sin embargo, ahí está la cuestión; sea cual sea la razón por la que se ha borrado un registro, con este método no existe la posibilidad de perder un número, dado que cuando se inserte un nuevo registro será recuperado automáticamente. (Obviamos la legalidad/ilegalidad de las facturas).

Empezado por Lepe

¿Pero de qué hablamos? En tablas de escritorio sí hay diferencia entre llamar al método Append o al método Insert, respecto a la posición física del registro en la BBDD. En tablas sql, (como se habla en este hilo) no hay diferencia, ya que siempre usaremos un ORDER BY.

Esta es la madre del cordero. Precisamente cuando se "recupera" un registro de la tabla de huecos, el nuevo registro se ORDENA al número recuperado, y consecuentemente al ocupar su orden es cuando será perdido de vista por el usuario. No se si me explico, aunque esto es un fastidio, también existe la posibilidad de posicionarse sobre el nuevo registro, sabiendo a priori el número que la BD le va a asignar.

Empezado por Lepe

Ya no sé si hablamos de aislamiento de las transacciones, de inserciones o de qué, lo siento .
Eso mismo espero yo Saludos

En definitiva, que cada maestrillo tiene su librillo, y hablando se entiende la gente. Naturalmente lo que yo comento no es la "piedra filosofal", pero funciona y bastante bien.

Saludetes