PUNTO DE VENTA
33 views
Skip to first unread message
Hitiel Hernandez B.
Jun 21, 2010, 7:10:28 PM6/21/10
to VFP Grupo de Google
Hola Amigos!
una vez más recurro a sus sabios consejos, resulta que me han pedido hacer un Punto de Venta para un Café, la verdad
nunca he creado ninguno y hoy vengo a ustedes para que me iluminen. Ya que quiero hacerlo bien "chilero",
espero sus instrucciones. Gracias!
Saludos
Connect to the next generation of MSN Messenger Get it now!
una vez más recurro a sus sabios consejos, resulta que me han pedido hacer un Punto de Venta para un Café, la verdad
nunca he creado ninguno y hoy vengo a ustedes para que me iluminen. Ya que quiero hacerlo bien "chilero",
espero sus instrucciones. Gracias!
Saludos
Connect to the next generation of MSN Messenger Get it now!
panchimancuso
Jun 21, 2010, 10:42:34 PM6/21/10
to Comunidad de Visual Foxpro en Español
mira el tema es un poco amplio, yo te recimiendo que hagas un buen
estudio previo de lo que necesitan , a groso modo te diria que
empieses a crear tus tablas maestras ya sea ARTICULOS , FAMILIAS Y
SUBFAMILIAS DE ARTICULOS , VENTAS , DETALLEVENTAS , PROVEEDORES ,
FORMAS DE PAGO , CLIENTES , MESAS , MOZOS , CADETES, y algunas mas que
tu creas comveniente , yo tengo un sistema para una rotiseria y la
verdad me llevo bastante tiempo depurarlo, bueno espero poder ayudarte
en algo .
saludos
On 21 jun, 20:10, Hitiel Hernandez B. <hitie...@hotmail.com> wrote:
> Hola Amigos!
>
> una vez más recurro a sus sabios consejos, resulta que me han pedido hacer un Punto de Venta para un Café, la verdad
>
> nunca he creado ninguno y hoy vengo a ustedes para que me iluminen. Ya que quiero hacerlo bien "chilero",
>
> espero sus instrucciones. Gracias!
>
> Saludos
>
> _________________________________________________________________
> Connect to the next generation of MSN Messenger http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&s...
estudio previo de lo que necesitan , a groso modo te diria que
empieses a crear tus tablas maestras ya sea ARTICULOS , FAMILIAS Y
SUBFAMILIAS DE ARTICULOS , VENTAS , DETALLEVENTAS , PROVEEDORES ,
FORMAS DE PAGO , CLIENTES , MESAS , MOZOS , CADETES, y algunas mas que
tu creas comveniente , yo tengo un sistema para una rotiseria y la
verdad me llevo bastante tiempo depurarlo, bueno espero poder ayudarte
en algo .
saludos
On 21 jun, 20:10, Hitiel Hernandez B. <hitie...@hotmail.com> wrote:
> Hola Amigos!
>
> una vez más recurro a sus sabios consejos, resulta que me han pedido hacer un Punto de Venta para un Café, la verdad
>
> nunca he creado ninguno y hoy vengo a ustedes para que me iluminen. Ya que quiero hacerlo bien "chilero",
>
> espero sus instrucciones. Gracias!
>
> Saludos
>
> Connect to the next generation of MSN Messenger http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&s...
Manuel Zevallos
Jun 22, 2010, 12:05:27 AM6/22/10
to publice...@googlegroups.com
Hola....pues te recomiendo primero que hagas un levantamiento de informacion y segun eso puedes saber que es lo que se necesita para cumplir los objetivos.
Yo hice un sistema de punto de venta para un grifo que maneja gran cantidad de informacion.\
Atte.,
Manuel Zevallos
Gilberth Grissom
Jun 22, 2010, 9:38:57 AM6/22/10
to publice...@googlegroups.com
Saludos amigos, respecto a este tema y la forma como llamas a tus archivos he podido contrastar la forma como trabajo y lo que encuentro a veces en otros desarrollos:
- A menudo cuando nombro a mis archivos de base de datos trato de usar diversos mnemonico como: mcliente (para el maestro de clientes), marticulos (para el maestrio de articulos) y testado (para la tabla de parametros de estado) y tambien para los nombres de los campos
- Sin embargo he visto en algunas empresas que cuando ponen el nombre a las tablas siguen como lo siguiente: medicos (para la tabla de medicos), pago (para la tabla de pagos), y cuando se trata de nombrar las columnas, le ponen: paterno, materno, nombres.
Mi pregunta es y tambien para ayudar al amigo : ¿cual de estas practicas son las correctas?, usar los menomonicos o notacion polaca o usarlo como se le llama en la realidad.
Como un aporte para el amigo que hizo esta pregunta le recomendaria dos casos:
Lee sobre el Analisis y Diseño Orientado a Objetos con Enforque Iterativo (bien util y practico)
Considera realizar la interfaz para el manejo a punta de teclado, he podido ver que en situaciones de alto trafico de gente, el pulsar tecla enter para ingersar y saltar los controles es mas util para el usuario...
saludos
Grisson
El 21 de junio de 2010 21:42, panchimancuso <panchi...@gmail.com> escribió:
--
Grissom
Luis Mata
Jun 22, 2010, 6:49:36 AM6/22/10
to publice...@googlegroups.com
Ninguno de los 2 modos causa problemas, usa el
que quieras mientras indique lo que es: conozco a personas que con la "Finalidad
de proteger sus sistemas" ponen a clientes como xr0001 y cosas que no tienen
sentido ni relacion. en este mundo globalizado hacer eso me parece tonto e
denota inseguridad profesional. Comento esto porque hay empresas que me han
llamado para poder auditar sus sistemas, ver una base de datos de ese tipo causa
una tremenda perdida de tiempo ademas cuando traes un empleado nuevo y quieras
que aprenda tu desarrollo debe de ser un rollo y pobre si le toca dar
soporte.
Como dice Sprite: las cosas como son.
Luis Mata
extremo
Jun 22, 2010, 10:26:28 AM6/22/10
to Comunidad de Visual Foxpro en Español
Hitiel
Otra cosa que tienes que tener presente en el diseño del programa es
diseñar la BD pensando en ventas de pack, por ejemplo si es un
software para un cafe, probablemente al cargar al cliente el combo 1
va de regalo un chocolate, por ejemplo, pero esa promocion es valida
hasta 7 dias mas, ademas debes tener en cuenta que al vender un
producto en pack, los precios cambian ejemplo:
combo 1
consta de los sifguientes productos:
cafe
churrasco
helado
total combo1 $1500
ahora al venderlo por separado
cafe = $480
churrasco = $1100
helado = $300
Total = $1880
Otra cosa a tener en cuenta el producto que ingresas al sistema es
combo1, pero internamente el sistema debe descontar stock al
cafe ,churrasco y helado si es que vas a manejas stock,
y por ultimo debes tener super claro como vas a imprimir las boletas ,
que maquinas se van a utilizar ejemplo impresora fiscal, etc.
Espero haberte sido de ayuda
Bendiciones
Otra cosa que tienes que tener presente en el diseño del programa es
diseñar la BD pensando en ventas de pack, por ejemplo si es un
software para un cafe, probablemente al cargar al cliente el combo 1
va de regalo un chocolate, por ejemplo, pero esa promocion es valida
hasta 7 dias mas, ademas debes tener en cuenta que al vender un
producto en pack, los precios cambian ejemplo:
combo 1
consta de los sifguientes productos:
cafe
churrasco
helado
total combo1 $1500
ahora al venderlo por separado
cafe = $480
churrasco = $1100
helado = $300
Total = $1880
Otra cosa a tener en cuenta el producto que ingresas al sistema es
combo1, pero internamente el sistema debe descontar stock al
cafe ,churrasco y helado si es que vas a manejas stock,
y por ultimo debes tener super claro como vas a imprimir las boletas ,
que maquinas se van a utilizar ejemplo impresora fiscal, etc.
Espero haberte sido de ayuda
Bendiciones
Victor Espina
Jun 22, 2010, 11:13:46 AM6/22/10
to Comunidad de Visual Foxpro en Español
Yo he usado ambos protocolos para nombrar mis tablas y columnas, y lo
que mejor resultado me ha dado hasta ahora es esto:
1. Usar nombres reales para los nombres de las tablas: Clientes,
Proveedores, Pagos, detalleFacturas, etc
2. Usar nombres compuestos para los campos, siguiente el siguiente
formato: xxxYyyyZzzz, donde:
xxx = prefijo de 3 letras único para cada tabla, ej: cli
(Clientes), fac (Facturas), dfa (detalleFactura).
YyyyZzzz = nombre de la columna, usando mayúsculas solo para la
primera letra de cada palabra, ej: cliCodigo, cliFechaNac, facNumero,
etc.
3. Utilizar nombres únicos para la misma columna, sin importar en que
tabla se encuentre. Por ejemplo, mucha gente llamada CODIGO a la
columna donde se almacena el codigo del cliente en la tabla CLIENTES,
pero la misma columna la llama CODCLIENTE dentro de la tabla FACTURAS,
para no chocar con una posible columna CODIGO en FACTURAS. En mi
esquema, la columna cliCodigo representa el codigo del cliente sin
importar la tabla donde este ubicado.
4. Para indices simples, usar el mismo nombre de la columna, pero
anteponiendo la letra "X", ej: XCLICODIGO, XFACNUMERO.
Otra regla que uso mucho es usar exclusivamente mayusculas para las
distintas partes de los comandos SQL, y respetar una rigurosa
identacion. Por ejemplo, en lugar de escribir:
Select a.*, B.cliNombre from Facturas a, Clientes b ;
where a.cliCODIGO = b.CLIcodigo AND a.facTipo = 'FA' order By
a.numfactura
hago en esfuerzo consciente en escribirlo de esta forma desde la
primera vez
SELECT a.*, b.cliNombre ;
FROM Facturas a, Clientes b ;
WHERE a.cliCodigo = b.cliCodigo ;
AND a.facTipo = 'FA' ;
ORDER BY a.numFactura
Lleva un poco mas de trabajo, sobre todo al principio, pero permita
una mucho mayor claridad a la hora de depurar el codigo, sobre todo
con queries complejos.
Saludos
Victor Espina
que mejor resultado me ha dado hasta ahora es esto:
1. Usar nombres reales para los nombres de las tablas: Clientes,
Proveedores, Pagos, detalleFacturas, etc
2. Usar nombres compuestos para los campos, siguiente el siguiente
formato: xxxYyyyZzzz, donde:
xxx = prefijo de 3 letras único para cada tabla, ej: cli
(Clientes), fac (Facturas), dfa (detalleFactura).
YyyyZzzz = nombre de la columna, usando mayúsculas solo para la
primera letra de cada palabra, ej: cliCodigo, cliFechaNac, facNumero,
etc.
3. Utilizar nombres únicos para la misma columna, sin importar en que
tabla se encuentre. Por ejemplo, mucha gente llamada CODIGO a la
columna donde se almacena el codigo del cliente en la tabla CLIENTES,
pero la misma columna la llama CODCLIENTE dentro de la tabla FACTURAS,
para no chocar con una posible columna CODIGO en FACTURAS. En mi
esquema, la columna cliCodigo representa el codigo del cliente sin
importar la tabla donde este ubicado.
4. Para indices simples, usar el mismo nombre de la columna, pero
anteponiendo la letra "X", ej: XCLICODIGO, XFACNUMERO.
Otra regla que uso mucho es usar exclusivamente mayusculas para las
distintas partes de los comandos SQL, y respetar una rigurosa
identacion. Por ejemplo, en lugar de escribir:
Select a.*, B.cliNombre from Facturas a, Clientes b ;
where a.cliCODIGO = b.CLIcodigo AND a.facTipo = 'FA' order By
a.numfactura
hago en esfuerzo consciente en escribirlo de esta forma desde la
primera vez
SELECT a.*, b.cliNombre ;
FROM Facturas a, Clientes b ;
WHERE a.cliCodigo = b.cliCodigo ;
AND a.facTipo = 'FA' ;
ORDER BY a.numFactura
Lleva un poco mas de trabajo, sobre todo al principio, pero permita
una mucho mayor claridad a la hora de depurar el codigo, sobre todo
con queries complejos.
Saludos
Victor Espina
Luis Mata
Jun 22, 2010, 7:48:00 AM6/22/10
to publice...@googlegroups.com
Esta es una buena practica.
Luis
----- Original Message -----
From: "Victor Espina" <vesp...@gmail.com>
To: "Comunidad de Visual Foxpro en Espa锟給l"
<publice...@googlegroups.com>
Sent: Tuesday, June 22, 2010 10:13 AM
Subject: [vfp] Re: PUNTO DE VENTA
Yo he usado ambos protocolos para nombrar mis tablas y columnas, y lo
que mejor resultado me ha dado hasta ahora es esto:
1. Usar nombres reales para los nombres de las tablas: Clientes,
Proveedores, Pagos, detalleFacturas, etc
2. Usar nombres compuestos para los campos, siguiente el siguiente
formato: xxxYyyyZzzz, donde:
xxx = prefijo de 3 letras 锟絥ico para cada tabla, ej: cli
(Clientes), fac (Facturas), dfa (detalleFactura).
YyyyZzzz = nombre de la columna, usando may锟絪culas solo para la
primera letra de cada palabra, ej: cliCodigo, cliFechaNac, facNumero,
etc.
3. Utilizar nombres 锟絥icos para la misma columna, sin importar en que
Saludos
Victor Espina
> Otra cosa que tienes que tener presente en el dise锟給 del programa es
> dise锟絘r la BD pensando en ventas de pack, por ejemplo si es un
Victor Espina
Jun 22, 2010, 11:24:27 AM6/22/10
to Comunidad de Visual Foxpro en Español
Hola.
Yo empezaria por preguntar al cliente cual es la razon que lo lleva a
optar por un desarrollo propio en lugar de intentar con un producto ya
existente.
En mi experiencia, el desarrollo a la medida de este tipo de software
tan complejo rara vez termina en beneficio para el programador, pues
el cliente nunca va a entender la cantidad de trabajo que se requiere
para lograr algo como esto. Para el cliente, se trata de un simple
"sistemita" para controlar sus ventas, y generalmente uno termina
cobrando lo que el cliente esta dispuesto a pagar en lugar de lo que
realmente nos cuesta en H/H el trabajo.
Para nosotros como programadores, la inversión en este tipo de
programas solo se justifica si existe la posibilidad cierta de vender
el mismo programa a otros clientes, ya que esta es la UNICA forma de
en verdad recuperar la inversion realizada en tiempo y esfuerzo.
En mi vida profesional me ha tocado muchas veces esta situacion, y
siempre he preferido ser claro con el cliente y recomendarlo algun
sistema que ya exista. Solo en el caso de que el cliente tenga algun
requerimiento de operaciones tan especial que no puede cubrirse con
software ya existente, y luego de asegurarme que el cliente entiende
aunque sea medianamente la clase de esfuerzo que requiere desarrollar
un sistema como este, es que me he embarcado en el tema de los
desarrollos a la medida.
Mi recomendación final, en caso que sigas adelante con tu proyecto
seria que:
1. Te asegures de evitar en lo posible desarrollar funcionalidad que
sea demasiado particular para ese cliente especifico. Mientras mas
genérico sea tu sistema, mas probabilidad tendrás de venderlo a otros
clientes sin necesidad de modificar nada.
2. Negocia con tu cliente un precio por la LICENCIA, NO por el
desarrollo, o también vendele la idea de que el precio que le das NO
INCLUYE los derechos sobre los fuentes. Tu le vendes el DERECHO a usar
el programa; no el programa en si. Esto te permitirá utilizar ese
código en otros proyectos sin problema alguno.
3. Investiga cuales son las funcionalidades basicas que ofrecen los
productos ya existentes, asi como sus debilidades y fortalezas. Esto
te permitira definir mas claramente que cosas queires
Saludos
Victor Espina
On 21 jun, 19:10, Hitiel Hernandez B. <hitie...@hotmail.com> wrote:
> Hola Amigos!
>
> una vez más recurro a sus sabios consejos, resulta que me han pedido hacer un Punto de Venta para un Café, la verdad
>
> nunca he creado ninguno y hoy vengo a ustedes para que me iluminen. Ya que quiero hacerlo bien "chilero",
>
> espero sus instrucciones. Gracias!
>
> Saludos
>
> _________________________________________________________________
> Connect to the next generation of MSN Messenger http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&s...
Yo empezaria por preguntar al cliente cual es la razon que lo lleva a
optar por un desarrollo propio en lugar de intentar con un producto ya
existente.
En mi experiencia, el desarrollo a la medida de este tipo de software
tan complejo rara vez termina en beneficio para el programador, pues
el cliente nunca va a entender la cantidad de trabajo que se requiere
para lograr algo como esto. Para el cliente, se trata de un simple
"sistemita" para controlar sus ventas, y generalmente uno termina
cobrando lo que el cliente esta dispuesto a pagar en lugar de lo que
realmente nos cuesta en H/H el trabajo.
Para nosotros como programadores, la inversión en este tipo de
programas solo se justifica si existe la posibilidad cierta de vender
el mismo programa a otros clientes, ya que esta es la UNICA forma de
en verdad recuperar la inversion realizada en tiempo y esfuerzo.
En mi vida profesional me ha tocado muchas veces esta situacion, y
siempre he preferido ser claro con el cliente y recomendarlo algun
sistema que ya exista. Solo en el caso de que el cliente tenga algun
requerimiento de operaciones tan especial que no puede cubrirse con
software ya existente, y luego de asegurarme que el cliente entiende
aunque sea medianamente la clase de esfuerzo que requiere desarrollar
un sistema como este, es que me he embarcado en el tema de los
desarrollos a la medida.
Mi recomendación final, en caso que sigas adelante con tu proyecto
seria que:
1. Te asegures de evitar en lo posible desarrollar funcionalidad que
sea demasiado particular para ese cliente especifico. Mientras mas
genérico sea tu sistema, mas probabilidad tendrás de venderlo a otros
clientes sin necesidad de modificar nada.
2. Negocia con tu cliente un precio por la LICENCIA, NO por el
desarrollo, o también vendele la idea de que el precio que le das NO
INCLUYE los derechos sobre los fuentes. Tu le vendes el DERECHO a usar
el programa; no el programa en si. Esto te permitirá utilizar ese
código en otros proyectos sin problema alguno.
3. Investiga cuales son las funcionalidades basicas que ofrecen los
productos ya existentes, asi como sus debilidades y fortalezas. Esto
te permitira definir mas claramente que cosas queires
Saludos
Victor Espina
On 21 jun, 19:10, Hitiel Hernandez B. <hitie...@hotmail.com> wrote:
> Hola Amigos!
>
> una vez más recurro a sus sabios consejos, resulta que me han pedido hacer un Punto de Venta para un Café, la verdad
>
> nunca he creado ninguno y hoy vengo a ustedes para que me iluminen. Ya que quiero hacerlo bien "chilero",
>
> espero sus instrucciones. Gracias!
>
> Saludos
>
> Connect to the next generation of MSN Messenger http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&s...
extremo
Jun 22, 2010, 12:04:38 PM6/22/10
to Comunidad de Visual Foxpro en Español
Excelente Victor
Fue muy educativo
Bendiciones
Fue muy educativo
Bendiciones
Hitiel Hernandez B.
Jun 22, 2010, 11:21:29 AM6/22/10
to VFP Grupo de Google
gracias,gracias
creo que sí, tomaré en cuenta todo lo que me dices. No no había pensado
gracias!
> Date: Tue, 22 Jun 2010 07:26:28 -0700
creo que sí, tomaré en cuenta todo lo que me dices. No no había pensado
gracias!
> Date: Tue, 22 Jun 2010 07:26:28 -0700
> Subject: [vfp] Re: PUNTO DE VENTA
Get news, entertainment and everything you care about at Live.com. Check it out!
Reply all
Reply to author
Forward
0 new messages