Que archivos libres usar
 

hola a todos... tratare de explicarme un poco para poder recibir su valiosa opinion.
Tengo una aplicacion win32 hecha con D7 + Firebird 1.5. Actualemente tengo una aplicacion la cual funciona como facturacion en el mostrador esta esta trabajando on-line contra un servidor con firebird. Todo anda de maravillas, salvo por un problema, que cuando se cae el servidor por alguna causa la linea de cajas deja de funcionar. (esto es logico que pase... y es lo mas normal) peeeeerooo tengo un cliente importante en donde quiere que se siga facturando pase lo que pase con el servidor, la red, los astros, etc etc etc.
He pensado una solucion y es que la aplicacion de facturacion trabaje con los archivos en forma local, es decir que grabe y consulte en su disco y que cada X tiempo acceda al servidor (si esta disponible) y copie todas las novedades. Se que no es lo mejor... pero bueno no queda otra... el problema y la duda es la siguiente....
¿Que sistema de archivos uso en forma local? Deberia ser algo en donde esten los archivos libres y que cumplan las siguietnes caracteristicas:
-Velocidad de acceso, lectura e insercion.
-Robustes.... no quiero que se corrompan indices, etc etc
-Acceso por medio de algun componente si es DBExpress mejor.... (porque esos uso para firebird)
-Que mantenga los archivos de indices dentro del mismo archivo...
y alguna otra ventajilla que se me esta olvidando...

He pensado poner Firebird en cada caja y trabajarlo en forma local... pero no se como resultaria.....

¿que opinan ustedes ?

Saludos y gracias

Pues yo arreglaría ese servidor para que no se "caiga" y se acabó el problema.


Por cierto, el título no sé a qué viene: " Que archivos libres usar" :S

Si... yo tambien... no es un problema de caidas por fallas sino por errores o "capricos"....

y puntualmente el hilo es para consultar que experiencia tienen sobre archivos libres... (no bases de datos) al estilo DBF por ejemplo...

En eso todos van a tener razón. Un servidor bien montado no tiene por que caerse...ahora que no mencionas que está corriendo en ese servidor. Un servidor para una línea de cajas (en eso si tengo mucha experiencia) podemos considerarlo incluso como de "misión crítica" y debe contar con algún tipo de redundancia.

Mi recomendación sería:

1.- Monta otro servidor esclavo que se actualice en automático y en casod e que falle el otro que entre a dar servició el, al volver a poner el principal éste deberá actualzarse y retomar el control. Todo esto debe pasar de manera transparente para tus cajas.

2.- Si no hay para poner otro servidor o bien hacer las adecuaciones al software:
Cada caja (vamos, el software que hace de caja) deberá poder registrar sus transacciones en forma local (en el sistema de archivos que mas te guste, Paradox, por ejemplo) pero, al no tener acceso al servidor no podrá hacer búsquedas al catálogo de artículos y por lo tanto a los precios de los mismos. Por lo que el cobro se tendría que hacer "a la antigüita" (departamento-precio). Al regresar el servidor, cada caja tendría que ir actualizando sus registros a la DB, pero obviamente no hay forma de saber que artículos se vendieron , solo los importes. Esto se tendría que hacer de forma manual.

Este esquema es el que maneja el sistema de software IBM POS 3794.

Finalmente y muy importante:
- NO USES WINDOWS para el servidor.
- El servidor es precisamente eso, un equipo dedicado solo a eso, nada de ocupar la PC mas grandota que es la que además usa el gerente o el dueño.
- Configuralo bien y limita al máximo las caídas, que no deben existir.

Obviamente podrás encontrar otras soluciones, pero todas serán como dicen los españoles, a base de chapuzas.

Por cierto, si a alguien le interesa, tengo la información necesaria para desarrollar un sistema de POS robusto basado en el funcionamiento del que comenté de IBM (que casi es standard en muchos supers como Wal-Mart), hace falta software Open Source de este tipo.

bueno pues nada que ver con el hilo :D pero si ojala y puedas compartir la informacion que mencionas se agradeceria

Como que nada que ver? Brandolin pregunta como poner Firebird local en sus cajas para poder seguir usandolas cuando se cae el servidor... Casimiro y yo coincidimos en que la solucion no es buscarle por ahi...sino buscar alternativas para evitar ques el caiga el servidor.

Tambien comento a Brandolin que puede usar un esquema basado en tablas planas Paradox y le doy una alternativa (muy generica por cierto) sobre como hacer el modelo.

Gracias a todos por las respuestas... les comento un poco para hechar un poco de luz y mejorar un poco...
La experiencia que tengo en lineas de caja (supermercados) es mucha y he trabajado con muchos sistemas, la mayoria de ellos trabajan contra un servidor (incluido el IBM, cadenas como WallMart, Disco, etc la usan y hago el mantenimiento a dicho sistema) el problema surgue cuando hay un corte de energia, caidas del servidor, fallas en la UPS, etc etc esto afecta directamente a las ventas en la linea de cajas, ya que hasta que no esta el servidor on-line no se puede vender, y el inicio de la linea de cajas luego de una falla critica demora mas de 20 mins (este es el caso de IBM).
Aca en argentina existe (es mas yo lo he instalado) un buen sistema de lineas de cajas llamado Prodigy que utiliza un diagrama de almacenamiento local en cada caja hacendo las actualizaciones de ventas en cada ticket (bidireccional) el problema que tiene este soft es que usa tablas Btrieve, que no son malas pero un poco antiguas y su acceso no es compatible con D7 o superiores, ademas de ser pago (la licencia de Pervasive es carisima).
Por eso ahora que estoy comenzando con el desarrollo de esta nueva aplicacion para este cliente quieria opiniones de que seria lo mejor para poner en cada caja.....

PD: AzidRain, estoy interesado en desarrollar un punto de venta generico Open source... definitivamente no existe nada como el estilo y creo que seria de mucha utilidad para los comercios.... estoy dispuesto a participar activamente de este tipo de iniciativas.

Saludos,

Aquí un tpv opensource, aunque hay más.

MIra, yo trabaje en Wal_mart mucho tiempo (casi 5 años) y nunca me tocó ver que se cayera nada...El esquema como trabaja el POS es muy robusto y totalmente a prueba de fallos. Se usa el esquema de un controlador maestro y un esclavo como redundancia y cada caja puede cobrar en forma autónoma. Además de eso todos las cajas y los controladores tienen sus UPS correspondientes de mas de 1 hr de respaldo adicionado a una planta de energía.

INclusive podías apagar completamente alguno de los dos controladores y en las cajas ni se notaba nada...Tambièn podías apagar completamente los dos y las cajas seguían cobrando aunque se reducían algunas funcionalidades. La verdad es un esquema muy potente

A mi la verdad me gustó mucho y obviamente recopilé información necesaria para que cuando pudiera hacer un sistema similar.

Ya cheqé la opción que nos paso Casimiro pero va enfocada a "hosteleros" como les dicen en España o bien "tienditas","minisupers" o "tiendas de conveniencia" donde no tienes la misma carga de clientes que en un supermercado.

Lo que estoy seguro no existe es un punto de venta especializado que permita manejar miles de transacciones por hora y al menos 15 terminales a todo lo que dan. Quien ha trabajado en supermercados sabrá como se pone eso alredededor de las 7 de la noche de cada 24 de Diciembre (por poner un ejemplo)..

Pues yo estoy puesto para hacerlo falta ver quie mas se apunta y alguien que nos oriente sobre como manejar un proyecto a distancia...

Creo que comparto ampliamente las respuestas que se han dado al problema planteado.
En los bancos, en los cajeros automáticos, cuando no hay línea, permiten reintegrar dinero guardando las transacciones en local, sincronizandolas con el srv central cuando se restablece la línea. En la aplicación financiera que utilizan, en la mayoría de los casos, permiten hacer transacciones off-line, de igual manera, se graban en local y posteriormente se sincronizan.
Lógicamente, no todas las opciones posibles estarán disponibles, sólamente las mínimas.

El debate más importante en este caso, es qué quereis permitir realizar cuando se caiga el srv y qué necesitais para que funcione - vamos a llamarlo así - off-line.
Para las cajas, lo más importante es poder cobrar, por lo que entiendo que al menos tendrá que tener en local los datos de los artículos y su precio actual. Se podrían obviar en un primer momento las ofertas o descuentos promocionales. Otro dato importante es cuándo realizar la sincronización de estos datos del srv al pc ( lo digo por el volumen ) sin penalizar en tiempo a la cajera ( no sé porqué me ha salido en femenino :confused: ) asegurando que en cualquier momento de caída estén actualizados.
Lo mismo con la sincronización, que pueda configurarse cuándo hacerse ya que no será la primera vez que la sincronización 30 minutos después vuelve a tirar el srv por rendimiento.

Espero haberos sido de ayuda.

Un saludo

El problema es que luego quién le vende el programa a esa gran empresa, porque seguro que no lo van a cambiar por el que tienen.

Si, pero no se trataria de vender...sino de hacerlo Open source y liberarlo con GPL o similiar como ya dijimos.. hay muchas empresas pequeñas (PYMES) que no tienen el dinero para comprarse softwares tan grande como los que ya platicamos (o le meten al software o le mente a comprar mercancía para vender). De hecho muchas empresas se quedan rezagadas solo por no contar con un POS preciso, adecuado y que les ayude a bajar las mermas al mínimo. (válgase la expresión).

Cualquier empresa de estas pequeñas le entraria gustoso si no tiene que pagar las superlicencias ni nada. Además al ser GPL continuamente se estaría mejorando.

He ha puesto lindo el hilo... si basicamente lo que queria saber es que poner como archivos en la caja ya que segun lo que estoy desarrollando la caja guardaria solo los comprobantes que se van generando y los articulos pero mi problema es "que" archivos poner en las cajas... porque si se cae el servidor y se rompen los archivos en las cajas... la catastrofe esta a la vuelta de la esquina....
Por otro lado el del PVT Open Source estaria genial... como experiencia le comento que actualemtne en mi empresa tenemos un PVT casi open, solo se cobra por la instalacion y la capacitacion del personal....

Bueno... sigan colaborando...

Hola, viendo que utlizas firebird, se me ocurre una diea, mas no se como este la estucutra de tu informacion....



puedes tener firebird embebido en cada cliente.



al hacer una venta, guardas la informacon en el server, y en tu maquina local.


deberias tener el catalogo en linea de los productos(haciendo que cada vez que se actuelice un precio en el server, poner una bandera que caduque en un dia por ejemplo) y al prendel la maquina cleinte, el catalogo local cheque que articulos on nuevos y cuale stienen labandera y se actuelicen.


ahora, si hay un cortey el servidor queda fuera de linea, la aplciacion cliente ya debe de manejar esa situacion y enetra en modo de ejecucion local, que pasa entonces, como ya tienes el catalogo de articulos como esta el servidor.


las compras y sus detalles, se van guardando y como no peudes guardarlos en en el servidor porque estan caidos, es agrregarles otro campo bandera indicando que no estan en el ervidor, asi que al encender la maaquina al dia siguiente o mas perfecto seria que en cuanto se detecte que el servidor esta activo, vaya haciendo las transacciones. cosa que no tendria mucho problema por la integridad de la informaicon que seria unica para cada maquina cleinte.

id_puesto cliente, id_vendedor, id_compra, id_fecha,


bueno e suna idea

cielos, que horrible escribo

si una estructura de funcionamiento como la que planteaste es la que tenia en mente, mi unico problema era el tema de "¿que sistema de tablas sería el mas correcto para usar?". Eso de Firebird embebido me gusta... ¿como funciona? ¿Donde puedo buscar informacion? ¿Es trasnparente con el firebird comun?

Gracias

No es un esquema robusto ya que entonces no requieres una máquina sencilla como caja sino algo más grande...Ah por cierto no comenté que en el sistema planteado las cajas son diskless con una pequeña memoria temporal para guardar sus transacciones.

El esquema de guardar una copia del catálogo de artículos en cada terminal no es práctico:

1.- Un catálogo de una tienda regular(no tienditas, supermercados) anda en mas de 20 mil artículos
2.- El catálogo puede estarse actualizando constantemente: cambios de precio, recibo de mercancías, etc.
3.- La terminal no solo debe llevar la cuenta de que ha vendido sino cuantos y de que SKU para poder actualizar el inventario en forma correcta.

La sincronizacion no es problema porque ocurre en el momento que "regresa la línea", el servidor se pone a recuperar las cuentas de las terminales y solo hasta que termina nuevamente empieza a procesar el directamente.

Hay un servico en el background que se encarga de ir actualizando el archivo de transacciones y catálogo de artículos. Pero este no es en tiempo real, sino que se hace cada x segundos. Solo se da servicio en tiempo real a consultas de artículos.

Pero bueno, finalmente ya nos olvidamos de lo principal que decia Casimiro: No es mas sencillo buscar la forma de evitar que se caiga el Servidor?

¿qué es "casi" open? :)

Hola no me parece tan poco practico el tema de guardar todo en las terminales, hace un tiempo hacia el amntenimiento de sistemas de supermercados y lo que trabajaban on line(chekando contra el servidor) tenian mas problemas que satisfacciones, por lo que la forma de trabajo era la siguiente, al comenzar la jornada se transmitia el archivo de precios y de ofertas a todas las cajas, entonces estas que daban operativas pase lo que pase con el servidor. Durante la jornada laboral habia cambios de precio, entonces para solventar esto en las cajas habia un archivo que solo contenia los articulos que cambiaron el precio, por lo que al fichar primero se verifica contra este si no tiene cambio de precio. Un avez terminada la jornada se realiza un cierre de cajas con lo que se trae al servidor los archivos de stock, ventas, etc. y se los procesa en el servidor. Teniendo este esquema de trabajo veo que las cajas podrian tener una aplicacion que funcione con tablas paradox locales y el servidor funcione con firebird.
De esta forma funcionaba muy bien, y estaba instalado en cadenas de supermercados de hasta ocho sucursales con hasta 15 cajas, y funciona incluso un 24 a las 7 de la tarde:)
Bueno es solo un aporte sobre una experiencia personal, y creo que suma por lo que se esta tratando en este hilo, escucho opiniones.
Fede