Sugerencias sobre numeracion de facturas

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

[[Lepe]]

Creo que nos estamos desviando mucho del tema, quizás lo que expongo ahora es demasiado para el tema que nos ocupa.

La filosofía:
- Primero comprobamos que el generador está creado en la BBDD, de lo contrario, lo creamos (habría que inicializarlo a un valor... pero no lo incluyo en el código).
- Ya que existe, y tiene un valor, lo incrementamos y recogemos su número.

Código Delphi [-]
const ExisteGen = 'SELECT RDB$GENERATOR_NAME FROM RDB$GENERATORS WHERE  RDB$GENERATOR_NAME = %s and RDB$SYSTEM_FLAG IS NULL' ;

const CreaGen = ' CREATE GENERATOR %s';

const IncrementaGen = 'SELECT GEN_ID(%s , 1) FROM RDB$GENERATORS WHERE  RDB$GENERATOR_NAME = %s AND  and RDB$SYSTEM_FLAG IS NULL';

begin
NombreGen:= 'Facturas_'+ inttostr(2007); // Nombre del Generador incluyendo el año

qry.sql.text := format( existeGen, [QuotedStr(NombreGen)]);
qry.Open;
if qry.IsEmpty then
begin  
// vaya por dios, el generador no existe en la BBDD,
// si intentamos consultar su valor nos daría una bonita excepción
   qry.Close;
   qry.sql.text := Format(CreaGen, [NombreGen]); // pos creamos el generador
   qry.ExecSql;
   // aquí podríamos establecer su valor a cero, (sería lo lógico)
end;

qry.sql.text := Format(IncrementaGen, [NombreGen, QuotedStr(NombreGen)]);
qry.Open;
Result := qry.Fields[0].AsInteger; // el valor del generador, incrementado en 1

He tenido un problemilla con Firebird 1.5, y es que en un Store Procedure no se puede hacer algo asï:

Código SQL [-]
create generator :NameGen

Donde NameGen es el parámetro de tipo string que se pasa al Store Procedure. Pues bueno, salvamos el escollo desde delphi que no tiene restricciones.

PD: El código está escrito de memoria, aunque los sqls han sido probado desde el SQL Editor de IB Expert Personal.

Consecuencias de usar este método:
- El número de factura solo se pediría al guardar definitivamente la factura.
- Estando en red, podría dar fallos al crear los generadores, igual se podrían crear 50 generadores desde el principio, y así obviamos el tener que comprobar que existen y que tienen asignados un valor.

Saludos

[[ArdiIIa]]

Empezado por Lepe

Creo que nos estamos desviando mucho del tema, quizás lo que expongo ahora es demasiado para el tema que nos ocupa.

Perfecto Lepe:
A priori ese sistema me parece sofisticado e ingenioso, sin embargo tengo por costumbre no "hurgar" en las tablas del sistema, dado que en mis inicios de interbase, hice irrecuperable una base de datos tratando de ocultar las fuentes de la misma, y desde entonces son prohibidas para mi, no obstante viendo lo visto, sería cuestión primero reconsiderarlo y segundo quitarme el sombrero.

[ContraVeneno]

Empezado por ArdiIIa

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).

Pues de antemano te comento que todos los sitemas empresariales que he estado utilizando en los últimos años, no le permiten al usuario borrar ningún registro. Esto es para llevar un mayor control de las acciones que se realizan.

El estatus de los registros puede cambiar (activo, cancelado, obsoleto, cerrado, facturado, etc) pero jamás se eliminan registros.

Así que yo te podría decir que, los sistemas que permiten al usuario borrar registros, tienen un gran hueco de seguridad y control de su información.

Esto es cuando hablamos de sistemas que contienen información legal o vital para la empresa.

[[ArdiIIa]]

Empezado por ContraVeneno

Pues de antemano te comento que todos los sitemas empresariales que he estado utilizando en los últimos años, no le permiten al usuario borrar ningún registro. Esto es para llevar un mayor control de las acciones que se realizan. .

Empezado por ContraVeneno

El estatus de los registros puede cambiar (activo, cancelado, obsoleto, cerrado, facturado, etc) pero jamás se eliminan registros.

Me parece muy adecuado pero tajante....

Empezado por ContraVeneno

Así que yo te podría decir que, los sistemas que permiten al usuario borrar registros, tienen un gran hueco de seguridad y control de su información.

Esto es cuando hablamos de sistemas que contienen información legal o vital para la empresa.

Seamos un poco serios con aquello de la información legal y vital.
Recuerdo que hace unos años, mas o menos en los inicios del Club de Delphi, pululaba y pulula una empresa ""de cierto prestigio", la cual cuenta con una importante cartera de clientes, entre las que además del desarrollo de aplicaciones, impartía formación a programadores y se desarrolló un proyecto de gestión empresarial / contabilidad, que pretendía abarcar todos los ramos empresariales.
Bueno pues mira por donde, resulta que ese proyecto disponía de una doble contabilidad, la "legal" y la "otra" y mira por donde, resultó que la mayoría de las empresas que se interesaron por aquel proyecto, destacaban como principal virtud del proyecto, justamente esa faceta que te he comentado.
Estoy seguro que algunos de los usuarios de esta web, les suena de lo que estoy hablando.
Dicho esto; saca tus propias conclusiones.
Saludos