Re: modos de bloqueo

Puede ser un problema, no te lo discuto, pero depende el tipo de empresa
y el uso que le de, si la empresa hace bloques de facturación grandes,
lo lógico es que habilite otra serie de facturación o facture los
bloques grandes a otras horas. Tampoco es logico que estes facturando un
bloque de un cliente o varios cliente y aparezca una factura en medio de
otro cliente.

Este problema aparecería en empresas que facturen de manera quincenal o
mensual, que acumulen albaranes y no los facturen en el momento.

El 21/04/2016 a las 18:14, Ivan Perales M. escribió:
> Imaginate si a un cliente le van a hacer 100 facturas y a otro solo 1,
> pero el de 100 empezo primero, lo obligarás a esperarse el tiempo que
> tarde hacen esas 100 en lugar de solo el tiempo que tarde hacer la de el?.
>
> El método que te propuse lo puedes adaptar para que te aparte un rango
> de folios.
>
> En fin, suerte.
>
> 2016-04-21 11:06 GMT-05:00 Kernel <jucabapa(at)gmail(dot)com
> <mailto:jucabapa(at)gmail(dot)com>>:
>
> El 21/04/2016 a las 16:39, Ivan Perales M. escribió:
>
> Yo también creo que tu problema es una solución más por software
> que por
> la base de datos.
> Pero ahora, la pregunta sería, ¿el número de factura debe ser
> consecutivo?, si a un cliente se le van a hacer 100 facturas, y
> a otro
> solo 2, al primer cliente le deben de salir del 1 al 100 y al
> segundo
> del 101 al 102?, o puede ser posible que al cliente 1 le salgan
> del 1 al
> 102 y al cliente por ahi del 35 y 47, eso es factible? Por que
> si esto
> si lo es, yo creo que lo que deberias tener es un método
> exclusivo que
> ye este regresando el folio. Despues de hacer todas las
> validaciones en
> el método que crea la factura y ya lo único que queda es
> guardarla en la
> base de datos, en ese momento deberias llamar a éste método
> exclusivo
> (que debe crear una transaccion independiente) y que debe estar
> preparado para ser llamado desde diferentes threads, encolando las
> peticiones, asi el método exclusivo checa cual es el siguiente
> folio,
> actualiza la tabla y lo retorna, las siguientes peticiones entonces
> siempre recibirán el siguiente único. La ventaja de esto es que
> puedes
> agregar un parámetro adicional como la serie para obtener el folio.
>
> 2016-04-21 9:14 GMT-05:00 Jaime Casanova
> <jaime(dot)casanova(at)2ndquadrant(dot)com
> <mailto:jaime(dot)casanova(at)2ndquadrant(dot)com>
> <mailto:jaime(dot)casanova(at)2ndquadrant(dot)com
> <mailto:jaime(dot)casanova(at)2ndquadrant(dot)com>>>:
>
> 2016-04-21 8:03 GMT-05:00 Hellmuth Vargas <hivs77(at)gmail(dot)com
> <mailto:hivs77(at)gmail(dot)com>
> <mailto:hivs77(at)gmail(dot)com <mailto:hivs77(at)gmail(dot)com>>>:
>
> > Hola Lista
> >
> > Quisiera que aclaráramos y dividiéramos el problema en
> cuestión: la
> > necesitad del bloqueo es por los Item o artículos que
> hacen parte
> de la
> > factura para que otro cliente nos los vaya a tomar
> nuestros artículos
> > mientras se efectúa la factura o es por el numero de la
> factura?
> Porque
> > según estoy entendiendo en el hilo de la discusión el
> tema es el
> numero de
> > facturación, si es así no hay necesidad de bloquear las
> tablas,
> el tema es
> > con la secuencia que genera el numero de factura, que no
> debe
> tener saltos,
> > debe ser consecutivo, debe ser UNICO, que debe
> corresponder a un
> rango
> > valido, etc. etc y el enfoque es diferente para lograr
> esto de forma
> > concurrente.
> >
>
> El problema de usar secuencias es que si puede haber
> saltos, por
> ejemplo si
> se cancela la operación luego de haber tomado un valor de
> la secuencia.
> Pero el otro problema que podría haber, o al menos a mi me
> paso en
> Ecuador,
> es que el gobierno nos obligaba a imprimir un formato
> especifico en una
> imprenta y nosotros debíamos usar ese formato llenando los
> espacios en
> blanco pero la imprenta ya debía darte los números de las
> facturas así
> que si tenias varias personas facturando debías asegurarte que
> terminen las
> transacciones en el orden correcto para que coincidan con los
> números fisicos
> de la factura.
>
> Por supuesto, existe más de una manera de solventar ese
> problema pero el
> problema existe. Y seguramente hay variantes del mismo
> problema en
> otras partes.
>
> --
> Jaime Casanova www.2ndQuadrant.com
> <http://www.2ndQuadrant.com> <http://www.2ndQuadrant.com>
> PostgreSQL Development, 24x7 Support, Remote DBA, Training
> & Services
>
> -
> Enviado a la lista de correo pgsql-es-ayuda
> (pgsql-es-ayuda(at)postgresql(dot)org
> <mailto:pgsql-es-ayuda(at)postgresql(dot)org>
> <mailto:pgsql-es-ayuda(at)postgresql(dot)org
> <mailto:pgsql-es-ayuda(at)postgresql(dot)org>>)
> Para cambiar tu suscripción:
> http://www.postgresql.org/mailpref/pgsql-es-ayuda
>
>
>
>
> --
> Lindolfo Iván Perales Mancinas
> Solo existen 10 tipos de personas en el mundo, las que saben
> binario y
> las que no.
>
>
> Las facturas tienen que ser correlativas , sin saltos y por supuesto
> la fecha de una factura no puede ser menor que una con numero superior.
>
> Voy a utilizar el select for update con la clausula nowait a una
> tabla que voy a crear para el proceso, asi puedo bloquear por
> empresa,serie.
> No voy a hacer el select for update a la propia tabla de series, por
> que en el mismo registro esta el ultimo numero de
> factura,albaran,pedido,presupuesto, orden de fabricacion y
> bloquearia muchos procesos.
>
> Voy a leer el ultimo numero de factura al principio, lo incrementare
> en memoria y solo escribiré en el fichero de series al final, justo
> antes del commit, creo que es la mejor solución ..
>
>
>
>
>
>
> --
> Lindolfo Iván Perales Mancinas
> Solo existen 10 tipos de personas en el mundo, las que saben binario y
> las que no.

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda(at)postgresql(dot)org)
Para cambiar tu suscripcin:
http://www.postgresql.org/mailpref/pgsql-es-ayuda