[BulmaGés]BulmaTPV

Lun Nov 5 14:07:23 CET 2007

Perfecto !!, Veo que los problemas tenemos todos absolutamente los mismos.

Sobre el software éste. ¿Que licencia tiene ? ¿Podemos ver el código?
Y sobre la base de datos ¿Nos dejas mirar el esquema de base de datos?

Lo de la sincronizacion es difícil. Yo tengo planteado un sistema cliente 
servidor con un parseo de mensajes en XML con las PDA's. Funciona bastante 
bien y pensaba extender el protocolo para que todas las operaciones de 
sincronización fuesen a través de un demonio específico. Además el XML lo 
puedes extrader de la base de datos del cliente y dejarlo almacenado por si 
hay problemas y da bastante juego. 

De esta forma pensaba dejar elegir al cliente las frecuencias de 
sincronización para que se ajuste mejor a cada necesidad específica.

Ya que comentas lo de la PDA el otro dia encontré esto:
http://www.compulab.co.il/x270em/html/x270-em-datasheet.htm
Aunque supongo que ya lo conoces.

On Monday 05 November 2007 11:22:10 Daniel Jesús Pérez Burgos wrote:
> Hola!, yo tengo implementado con kylix un tpv, ahora estoy esperando que
> lazarus este un poco menos verde para migrar ya que kylix empieza a dar
> problemas ya que esta muy desactualizado. Os cuento un poco, lo tengo
> montado con mysql, trabaja sin la necesidad de un servidor online, de esta
> forma evito las caídas de adsl y uso el siguiente sistema  para actualizar
> los  datos:
>
> Numero las tablas con un sufijo que indica  el numero de tienda en el
> servidor, es decir creo la tienda en el servidor ejemplo con el número 1
> (ejem. que es Valencia)  pues se crean todas las tablas en el servidor con
> el sufijo 0001 ejem. arqueos0001, cajas0001, .... en el T.P.V. cliente
> defino el número que esta tienda tiene asignado al servidor, de esta forma
> al volcar los datos el cliente sabe a que tabla debe de ir.
>
> -Actualización de datos hacia el servidor.
> Cuando empecé a actualizar los datos me di cuenta que cuando se hacía en el
> momento de cobro, tardaba mucho. Para un programa de facturación o para una
> tienda donde "se puede esperar" no pasa nada el problema esta cuando es una
> tienda con mucha gente he impaciente. Lo que hice fue crear una tabla donde
> se guardan los  datos necesarios para procesar  artículos, cantidad,
> precio, total, fecha, hora, dependienta, entrega, cambio... y otro programa
> en segundo plano actualiza la base de datos liberando al sistema de la
> actualización al instante. Intenté crear un hilo pero kylix al mezclar VCL
> con CLX y tener partes emuladas, sobre todo la parte VCL con wine, daba
> muchos fallos así que lo hice en C. El programa cada 5 segundos busca en
> esa base de datos los tickets con entrega y cambio, que son los que están
> completados, actualiza las tablas, borra los datos de la tabla madre y así
> en bucle.
>
> El tema de la actualización remota. Primero desde el prograna en segundo
> plano iba creando un fichero que crecía crecía con las consultas mysql de
> inserción en el servidor y por cron iban volcando los datos en el servidor
> y después borraba el fichero, como entre que volcaba se podía seguir
> creando tickets  cuando empezaba el volcado el fichero lo movía a otro
> fichero dejando que se fuese generando otro mientras este era volcado, así
> tambien en bucle. Este sistema tiene un problema y son los cortes de luz
> y/o bloqueos del equipo ya que observe que el fichero se corrompía y las
> consultas SQL se quedaban medio hacer. Este sistema lo uso ahora sólo para
> los arqueos de esa forma si el arqueo de hace a las 3, a las 3:15 sabes el
> dinero que se ha hecho, sin necesidad de conectarte a la tienda o esperar
> al día siguiente, sobre todo si tienes 15. El resto de datos al final opte
> por hacer un dump de la base de datos por las noches y volcarlo en un tgz y
> el servidor con un script en cron por las noches recorre  los  tgz  y
> actualiza las tablas de las diferentes tiendas.
>
> -Actualización de datos desde el servidor:
> Por las noches cada tienda se conecta al servidor y "dumpea" las tablas de
> artículos y eans para que los datos dados de alta o actualizados  en el
> servidor aparezcan a la mañana siguiente en todas las tiendas.
>
> Con respecto a los dispositivos externos, son los que suelen dar mas
> problemas ya que se debe liberar al programa de la cola que le manda a la
> impresora ya que si la impresora esta apagada (o sin papel) el programa se
> queda esperando, así que creando un hilo con un tiempo de vida y un mensaje
> se soluciona el problema (para mí con kylix fue otra odisea).
>
> PDA.
> No tenemos PDA como tal sino algo parecido con un diseño más feo pero
> preparado para golpes y con lector de código de barras, he programado un
> programa para la CK1 de Intermec pero solo para hacer pedidos mediante la
> pistola de código de barras, esta ya esta descatalogada, y ahora estoy como
> sabes tomeu liado diseñando una en mis ratos libres.
>
> Por mi parte todo lo que pueda colaborar contad con ello.
>
> Saludos
>
> El día 4/11/07, Tomeu Borras <tborras en conetxia.com> escribió:
> > Bones a tothom.
> >
> >   Ya lo planteamos en la Asamblea de la asociación, lo explico en la
> > lista para conocimiento de todo el mundo.
> >
> >    Con el buen estado de BulmaFact, que ha alcanzado muy buen nivel de
> > funcionalidad, escalabilidad y que, mayormente, las ampliaciones que
> > deben hacerse son plugins que extienden el programa a funcionalidades
> > específicas
> > de cada tipo de negocio, labor que debería ser llevada a cabo desde la
> > iniciativa privada se ha empezado a plantear el afrontar una nueva pieza
> > vital en la gestión empresarial TPV.
> >
> >    He estado hablando con diversa gente con diversos puntos de vista
> > sobre como implementar el TPV. Este mail es un poco de recopilación de
> > información
> > cogida de unos y otros para ver si podemos concretar temas y llegamos a
> > un modelo que pueda satisfacer los gustos de cada uno.
> >
> >    Para mi, el TPV es una pieza de software cuya principal funcion es la
> > de
> > agilizar al máximo el proceso de ventas sacrificando, en cada tipo de
> > negocio, datos que no tienen importancia para el caso.
> >    Por ejemplo, la presupuestación no existe, el proceso de pedidos sólo
> > esta
> > presente en unos pocos procesos de negocio y el albaraneado y facturación
> > se
> > juntan en el proceso de compra. Aqui esta el primer tema, en el que hemos
> > coincidido todos. No debe atacarse el problema como varios TPV's
> > especificos
> > para cada modelo de negocio sino como un TPV modularizable que permita
> > agregar funcionalidades. Incluso debería ser un programa que no aporta
> > más que un par de funcionalidades muy básicas y que implemente el resto
> > de funcionalidades como modulos adicionales. Quiero decir con esto que el
> > TPV sin varios modulos cargados no serviria para nada. Y la importancia
> > residiria
> > en el conjunto.
> >
> >    El segundo gran tema en que hemos coincidido es que el TPV debería
> > poder
> > funcionar como un programa independiente y escalable en una red de TPV's.
> > Es
> > decir que ante un fallo (perdida de red o caida del servidor) El TPV
> > debería
> > poder seguir funcionando, y tener un proceso de sincronización de datos.
> >     Este punto lo que sugiere es que se implemente una capa de
> > sincronización
> > de datos, y ya que estamos en forma piramidal para poder crear
> > estructuras mucho más complejas (tienas, areas, paises). Y como no yo en
> > lugar de aplicar
> > capa de sincronización para TPV's crearía esta área para BulmaFact (que
> > es lo
> > mismo pero ampliado).
> >
> >    Base de datos de partida la de BulmaFact, también hemos coincidido
> > todos.
> >
> >
> >    Tecnología utilizada. Aqui está la mayor divergencia Web, Java, C+,
> > Python
> > Este es el punto donde cada uno defiende lo que más conoce.
> > Al hacerlo con tecnologia web sería rápido de implementar, fácil de
> > escalar, y
> > sacrificaría un poco el tema de la facilidad de manejo. También tendria
> > el problema del manejo de la ticketera (que es tambień sencillo si se
> > ejecuta en
> > local).
> > Los otros casos, creo que tienen exactamente las mismas ventajas que
> > inconvenientes.
> >
> >   No trataremos el tema de PDA's para hacer determinadas tareas ya que se
> > puede considerar un pequeño software complementario para introducir datos
> > en
> > la Base de Datos (no afecta en nada al TPV).
> >
> >    También está la posibilidad de usar TPV's existentes. En su momento
> > probamos con NTPV pero entre que está hecha con Qt3, centrada en
> > restauración
> > y que lleva dos años sin progresar no lo veo como punto de partida. Sin
> > embargo se pueden extraer y readaptar muchos componentes y tiene algunas
> > buenas ideas a considerar.
> >
> > Con este e-mail quedan expuestos los puntos clave para debate y
> > aportación de
> > ideas,
> >
> > Salut
> >
> > --
> > Tomeu Borrás Riera
> > Conetxia Soluciones informáticas
> > 902 88 11 66
> > 971 29 06 29
> > http://www.conetxia.com
> > _______________________________________________
> > BulmaGes mailing list
> > BulmaGes en bulma.net
> > http://llistes.bulma.net/mailman/listinfo/bulmages
> > Home: http://www.iglues.org
> > Wiki: http://www.iglues.org/wiki
> > Bugs: http://www.iglues.org/bugzilla

-- 
Tomeu Borrás Riera
Conetxia Soluciones informáticas
902 88 11 66
971 29 06 29
http://www.conetxia.com