[BulmaGés]BulmaTPV

[Daniel Jesús Pérez Burgos]

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
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://llistes.bulma.net/pipermail/bulmages/attachments/20071105/8838c489/attachment-0001.htm