12 replies to this topic

[enecumene]

Hola amigos, necesito consejos y/o ayuda de cómo realizar esta situación, tengo una tabla donde hay un campo incremental (1,2,3...N) y otro para el número de factura (ejemplo: 5555/09, No./año), ahora bien, el cliente que usa el sistema genera el número de factura por año, es decir, 01/09, 02/09 hasta donde llegue al 31/12/2009, pero en el 2010 la cuenta debe empezar de nuevo, 01/10, 02/10...etc, pero con el año correspondiente, quisiera saber ¿cómo harí­an ustedes que esa situación sea de manera automática?, con ejemplos eh  .

Saludos.

[eduarcol]

a ver yo lo manejaria de esta forma

delphi

if UltimoMesInicializado <> MesActual then
   Iniciocontador;
 
LeoContador;

[enecumene]

¿Tan sencillo no?  8-), gracias eduardo.

[eduarcol]

que tiene de malo lo sencillo?  8-)

me falto colocar que cuanto inicializas el contador inicias el ultimo mes...

[Delphius]

Hola Fernando,
Anoche vi el hilo y me quedé pensando. Tengo mis dudas y reservas sobre el tema... y viendo lo que comenta Eduardo debo decir ¡Momento!¡Paren el carro!

Antes que nada pregunto: ¿Es buena idea reiniciar la secuencia autonumérica? Se supone que el autonumérico es único.

¿En que medida esto puede afectar al diseño de tu base de datos? ¿Cómo está estructura tu base de datos?

En tu descripción nos comentas que tienes un campo autoincremental para las facturas, y luego tienes otro destinado para una tabla ¿Que tabla? Si estos mismos campos actuan de clave primaria y/o foráneas veo una practica peligrosa la de reiniciar el contador.

Si no es mucha molestia para comprender mejor el tema... ¿podrí­amos conocer un poco más del tema? ¿Es posible ver una diseño del DER o MER?

En cuanto al aspecto lógico, conceptualmente, es similar a como menciona eduardo. Ahora bien, hay que analizar en que medida se puede garantizar la integridad y consistencia de los datos.
Por lo que entiendo, se reinicia la cuenta de factura con el inicio del año... si es así­:

delphi

if AnioActual <> UltimoAnio
  then begin
           reiniciarNumeracionFacturas;
           UltimoAño := AnioActual;

Esta lógica se puede llevar dentro del sistema o la base de datos, o bien de forma conjunta entre sistema y base de datos. Tal vez el uso de triggers, procedimientos almacenados y otros elementos puedan ser últiles.

Saludos,

[enecumene]

Antes que nada pregunto: ¿Es buena idea reiniciar la secuencia autonumérica? Se supone que el autonumérico es único.

Hola Delphius, no, no es el campo autoincremental la que se reiniciará sino el otro campo que mencioné para esos fines.

En tu descripción nos comentas que tienes un campo autoincremental para las facturas, y luego tienes otro destinado para una tabla ¿Que tabla? Si estos mismos campos actuan de clave primaria y/o foráneas veo una practica peligrosa la de reiniciar el contador.

No amigo, creo que leí­ste mal, dije que tengo UNA tabla con esos dos campos uno incremental y el otro para generar la numeración de la factura.

Si no es mucha molestia para comprender mejor el tema... ¿podrí­amos conocer un poco más del tema? ¿Es posible ver una diseño del DER o MER?

Me vas a perdonar, pero desconozco lo que es DER o MER :$.

Saludos.

[Delphius]

Hola Fernando,
Gracias por las aclaraciones.

DER = Diagrama Entidad-Relación
MER = Modelo Entidad-Relación

Es lo mismo, algunos lo llaman DER; otros DER.
Es el diseño en donde se establecen visualmente las relaciones entre las tablas. Por ejemplo, éste.

Saludos,

[eduarcol]

Delphius, entiendo sobre manera tu preocupacion por la integridad de los datos, de hecho se me ocurren muchas razones para no hacerlo, pero hay una sola de peso, "el cliente lo quiere"

Tal como lo hizo Fernando no debe dar mucho problema, ya que la clave real si es correlativa, ese lo toma como un campo mas para satisfacer al cliente.

[Delphius]

No digo que esté incorrecto, yo más bien prefiero pensarlo dos veces.

Tal vez sea el "cliente quien lo pide" un motivo, pero creo que se puede ofrecerle un diseño y una solución que sea compatible con lo que necesita sin necesidad de recurrir a un reinicio.

Como dices, es un campo más. Y si, tal vez no le cause problemas y es una solución económica.

Disculpen si yo antes he entendido algo mal.

Saludos,

[Delphius]

Disculpen si soy molesto...
Es más, no es necesario disponer de un auto-incremental. Veamos... la información ya está ¿o no? El asunto es que al cliente no es la representación más adecuada. Entonces que hacemos, se la damos.

Se puede disponer de un trigger after insert que "calcule" el campo:

1) Lanzamos una consulta para saber la cantidad de registros del año en curso
2) Guardamos el valor en una variable, a falta de imaginación la llamo N.
3) Operamos:

3.1. El numero de registro de factura es N+1. Nro = N + 1.
3.2. Para el año tomamos los dos caracteres finales y lo almacenamos en Año.
3.3. Guardamos el valor del campo en cuestión con el formato Nro/Año.

Y como ven, nada de campos autoincrementales, reseteos, un simple trigger se encarga de "calcular" el campo a medida que se van ingresando. Luego tras una consulta uno puede mostrar el campo sin problemas.

No se si se me entiende. Tengo otras ideas, pero son un poquito más complicadas.
Saludos,

[eduarcol]

me gusta esa idea, elimina el problema que se ocasionaria si retrasan la fecha...

[Al González]

Secundando a Marcelo, entiendo que cada factura debe tener un campo Fecha.  Siendo así­, propongo que la estructura de la tabla tenga estos primeros campos:

ID.- Integer de llave primaria.
Fecha.- TimeStamp para fecha y hora de la factura.
Numero.- SmallInt para número consecutivo por año.
NumeroFormato.- Computado, concatenación del año del campo Fecha con el campo Numero bajo el formato que sugiera el cliente.

Con un disparador (trigger) Before Insert, para establecer el campo Numero en base al año del campo Fecha (último número de ese año más uno).

Dentro del disparador, la sentencia de asignación serí­a algo como:

sql

  -- Obtener el siguiente número de factura del año
  SELECT COALESCE (MAX (Numero), 0) + 1 FROM Factura WHERE EXTRACT (YEAR FROM Fecha) = 
    EXTRACT (YEAR FROM NEW.Fecha) INTO NEW.Numero;

Esto lo analicé con Firebird, sólo habrí­a que adaptarlo a las caracterí­sticas de MySQL.

Espero te sea de utilidad, Fernando. 

Saludos.

Al González.

[enecumene]

Muchas gracias Al, ya lo tengo anotado .

Saludos.