Modelo piloto

[Manuel Calero]

Hola a todos.

Estoy pensado y asi se lo comente a Javier, ir montando modelos pilotos.

A ver si me explico,mi idea es montar un mantenimiento de una de las tablas mas simples q podamos encontrarnos, en el desarrollo de la aplicación.

Para ello hemos elegido la tabla de Tipos de impuestos, q tiene solo 4 campos

Id, Impuesto, PorcentajeIVA, PorcentajeRecagoEquivalencia.

Para realizar este mantenimiento necesitaremos resolver puntos cruciales para el futuro.

Conexión con JQuery y Bootstrap.

Creación de tablas con los registros (adjunto imagen)

Estilo de codificación.

Soporte multiidioma.

Validación de formularios.

Muestra de mensajes a usuarios.

Seguridad.

Organización de las tablas dentro de la empresa.

Inclusión en menú principal de la aplicación.

Y algunas cosas mas q se nos irán ocurriendo.

Una vez claro como resolver este problema, acatar un mantenimiento relacionado, y q sean ejemplos de como ir ensamblando la aplicación.

Espero comentarios.

Saludos.

[Javier]

Bueno por mi bien a ver que dice la gente...

[Mario Lacunza]

Hola,

Perdon pero antes de nada no es fundamental definir el nombre del proyecto, alcances, licencias, participantes, roles, brainstorm y de alli sacar un documento con los requerimientos previos q deberan ser discutidos por los involucrados?? y despues con esto elaborar los modelos del sistama (UML) para basandose en esto empezar la etapa de codificacion??

Veo q ya hay a grosso modo algo de esto avanzando, pero proponer con unos dias de inicio hacer modelos de codigo de prueba parece una perdida de tiempo... por favor comencemos con la organizacion base del proyecto para despues tener las metas y objetivos para c/u de los participantes.. es mi opinion...

[Jordi Marco (ATHENON Services)]

Como controlar el tiempo de vigencia del porcentaje de los impuestos

--
Has recibido este mensaje porque estás suscrito al grupo "DjangoERP" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a djangoerp+...@googlegroups.com.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.
 
 

--
Jordi Marco Sanz 
Consultor en tecnología 

Mantenimiento Equipos, Servidores, Redes, 
Seguridad perimetral e interna.
Programación a medida:
python, django, jscript, html
ERP eneboo
CRM SugarCRM 

Tel: +34 691 805 769

“La competencia en el futuro no será entre grandes y pequeños sino entre rápidos y lentos” (Nikesh Arora, Vicepresidente de Google)

[Mario Lacunza]

Disculpa sigo sin entender tu pregunta q por lo menos no le veo q tenga
q ver con el desarrollo inicial del proyecto


Saludos / Best regards

Mario Lacunza
Email:: mlac...@gmail.com
Personal Website:: http://www.lacunza.biz/
OpenOffice.org Perú:: http://openoffice-peru.com/
Hosting:: http://mlv-host.com/
Mascotas Perdidas:: http://mascotas-perdidas.com/
Google Talk / Y! messenger / Skype: mlacunzav
MSN: mlac...@hotmail.com


El mar 30 abr 2013 10:17:09 PET, Jordi Marco (ATHENON Services)
escribió:

> Como controlar el tiempo de vigencia del porcentaje de los impuestos
>
>
> El 30 de abril de 2013 00:35, Manuel Calero

> <manuelca...@gmail.com <mailto:manuelca...@gmail.com>>

> <mailto:djangoerp%2Bunsu...@googlegroups.com>.

> Para obtener más opciones, visita
> https://groups.google.com/groups/opt_out.
>
>
>
>
>
> --

> */Jordi Marco Sanz/*/**
> Consultor en tecnología//

>
> Mantenimiento Equipos, Servidores, Redes,
> Seguridad perimetral e interna.
> Programación a medida:
> python, django, jscript, html
> ERP eneboo
> CRM SugarCRM

> /

> Tel: +34 691 805 769
>

> /“La competencia en el futuro no será entre grandes y pequeños sino
> entre rápidos y lentos” (Nikesh Arora, Vicepresidente de Google)/

[Manuel A. Estevez Fernandez]

Hola 

Estoy de acuerdo con Mario, un proyecto de este tamaño debe tener bien estructurado este tipo de bases. 

Debemos definir los alcances, y comenzar a tocar cada una de las áreas (grupos de módulos).

En el documento hay hasta el momento lo siguiente:

Usuarios

            Empresas

                           Delegaciones

                           Ejercicios

            Terceros (Clientes y proveedores)

            Productos

                           Familias

                           Categorías

                           Fabricantes //

                           Propiedades

            Operaciones

                           Compras

                                           Presupuestos

                                           Pedidos

                                           Albaranes

                                           Facturas

                                           Facturas rectificativas

                           Ventas

                                       Presupuestos

                                           Pedidos

                                           Albaranes

                                           Facturas

                                           Facturas rectificativas

                                           Tickets (Facturas simplificadas)

            Almacenes

                           Movimientos y regularizaciones artículos

            Tesorería

                           Divisas

                           Cobros y pagos

                           Formas de pago                          

Bancos

            Producción

                           Personal

                                       Secciones

                           Materiales producidos y consumidos.

            Contabilidad

                           Diarios contables

                           Plan contable

                           Asientos contables

Propongo un esquema más general en este momento para comenzar a definir de manera más clara.

Catalogos

Usuarios

Empresas

Divisas

Formas de Pago

Impuestos

Cuentas Contables

  Bancos

Clientes

Proveedores

Almacenes / Sucursales

Artículos

Clasificación (Familias / Categorías)

Operación

Compras

Ventas

Producción

Inventarios

Movimientos de entrada y salida

Kardex (registro de todos los movimientos a inventario por articulo)

Contabilidad

Diarios

Polizas

Reportes

Ya una vez establecidos avanzar el siguiente paso. 

Saludos.

  

[Javier Ramirez]

Para eso está para ir desarrollando entre todos

Desde el móvil disculpe las molestias

--

[Manuel Calero]

Mario

Me parece fantástico poder elaborar los modeles en UML, puedes encargarte tu de ello?

Y solo una sugerencia puedes empezar por un modelo pequeñito, para ir armando un prototipo (lease tablas de impuestos o países p.e.)

[Manuel Calero]

Jordi,

Ya habrá tiempo de complicar el modelo, pero si empezamos a complicarlo ya no avanzamos.

Partamos de algo muy simple.

[Manuel Calero]

[Javier Ramirez]

Buena idea lo de UML

Desde el móvil disculpe las molestias

--

[Mario Lacunza]

Hola,

No estoy seguro si voy a tener el tiempo ya que estoy con un par de proyecto grandes pero algo inventare.

Lo q mencionas parece un requerimiento puntual, las tablas de bases de datos se generan basandose en los modelos del sistema y no a la inversa.  Yo pienso igual q mientras no se tengan los modelos listos no se debe ni codificar ni avanzar con la BD, ya q es mas facil corregir los modelos q corregir codigo + bd si algo se tiene q modificar.. y creeme un sistema de este tipo se va a modificar bastante.

Saludos / Best regards

Mario Lacunza
Email:: mlac...@gmail.com
Personal Website:: http://www.lacunza.biz/
OpenOffice.org Perú:: http://openoffice-peru.com/
Hosting:: http://mlv-host.com/
Mascotas Perdidas:: http://mascotas-perdidas.com/
Google Talk / Y! messenger / Skype: mlacunzav
MSN: mlac...@hotmail.com

El 30/04/13 11:25, Manuel Calero escribió:

[Mario Lacunza]

Manuel,

te falta:  País esto mismo nos dice q debemos tener una opcion para los distintos Castellanos, por ejemplo aqui en Peru no sabria decirte q es Delegaciones??

Creo q clientes y proveedores son entes independientes pues cada uno mueve una parte distinta de la empresa.

Habria q hacer el flujograma de accion q cubrira la app.. por ejemplo una cotizacion se puede se puede convertir en un pedido y de alli en una venta q genera una salida de almacen y un comprobante de pago... este simple ciclo ya te movio todo el sistema...

Recordemas q la contabilidad no es standard y segun el pais cada uno tiene sus propios sistemas...

Asimismo una cosa es el diseño del flujo mismo del sistema y otra el diseño de la pantalla q el user accionara.. me parece q el diseño q planteas es mas para el 2do caso.

Bueno algunas q conversar... :)

Saludos / Best regards

Mario Lacunza
Email:: mlac...@gmail.com
Personal Website:: http://www.lacunza.biz/
OpenOffice.org Perú:: http://openoffice-peru.com/
Hosting:: http://mlv-host.com/
Mascotas Perdidas:: http://mascotas-perdidas.com/
Google Talk / Y! messenger / Skype: mlacunzav
MSN: mlac...@hotmail.com

El 30/04/13 10:41, Manuel A. Estevez Fernandez escribió:

[Manuel Calero]

Mario,

Encantado de tenerte en este proyecto.

Por otro lado quería comentarte q si preparamos un modelo muy pequeño (p.e. países imagina q la aplicación se basa solo en esa tabla)  podemos ir preparando muchas cosas sobre este mini modelo, y después ir extendiendo el modelo.

Como tu bien dices el modelo se tendrá q modificar bastante.

[Manuel Calero]

Mario

Totalmente de acuerdo con lo de distintos Castellanos, de echo la aplicación tiene q ser multiidioma.

En las pequeñas un medianas empresas, muchas veces se intercambian servicios o sea, un proveedor se convierte también en mi cliente, y viceversa, por eso es mejor aglutinarlos en una sola tabla.

La venta recoge siempre la baja del almacén  no hace falta hacer dos apuntes, hay q simplificar, para averiguar el stock de una articulo hay q consultar sus compras y sus ventas +- movimientos de almacén, y tendremos el stock.

Me gustaría ver en la practica un modelo muy pequeñito de lo q nos planteas.

Saludos.

[Mario Lacunza]

Este mensaje me llego 3 veces y este es distinto.. no olvidemos q
googlegroups por default no responde a la lista sino al remitente...


Te respondo entre lineas...

Saludos / Best regards

Mario Lacunza
Email:: mlac...@gmail.com
Personal Website:: http://www.lacunza.biz/
OpenOffice.org Perú:: http://openoffice-peru.com/
Hosting:: http://mlv-host.com/
Mascotas Perdidas:: http://mascotas-perdidas.com/
Google Talk / Y! messenger / Skype: mlacunzav
MSN: mlac...@hotmail.com

El 02/05/13 02:33, Manuel Calero escribió:

> Mario
>
> Totalmente de acuerdo con lo de distintos Castellanos, de echo
> la aplicación tiene q ser multiidioma.

Ingles te refieres? u otros?

>
> En las pequeñas un medianas empresas, muchas veces se intercambian
> servicios o sea, un proveedor se convierte también en mi cliente, y
> viceversa, por eso es mejor aglutinarlos en una sola tabla.

Aja ya vamos, cuando modelas un sistema no te refieres a las "tablas de
las BD" sino a las entidades, por lo tanto en el modelo tienes dos:
Clientes y Proveedores, como se almacenaran los datos es otro tema...

>
> La venta recoge siempre la baja del almacén no hace falta hacer dos
> apuntes, hay q simplificar, para averiguar el stock de una articulo
> hay q consultar sus compras y sus ventas +- movimientos de almacén, y
> tendremos el stock.
>

A ver por lo q se la venta "ordena" la baja de almacen y no al reves,
solo cuando se ejecuta la venta el stock cambia.

Sin embargo estamos yendo muy rapido.. hay cosas previas antes de ver
este modelo, ya se definio la licencia?? creo q es fundamental antes de
iniciar el proyecto xq por lo q lei en los previos no veo un consenso
con ella y esto puede originar q muchos entren al proyecto y otros se
vayan, asi podemos definir los recursos y roles..., yo propongo la LGPL
o BSD q dice el resto?? seria bueno iniciar un hilo distinto con este
item sugiero,

Tenemos q ordernarnos desde el inicio.

[Javier Ramirez]

LGPL

Desde el móvil disculpe las molestias

--
Has recibido este mensaje porque estás suscrito al grupo "DjangoERP" de Grupos de Google.

Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a djangoerp+unsubscribe@googlegroups.com.

[Mario Lacunza]

Copio al grupo ...

es cierto lo q dices pero al menos para mi es como decirle a un albañil: vete levantando una pared pero sin tener los planos de la casa hechos... si despues hay q tumbar esa pared?? a eso voy.. x eso yo al menos prefiero codificar al final cuando toda la fase de planeamiento y diseño este lista y aprobada por todos

Recordemos q por de pronto somos un grupo limitadisimo, voy viendo solo 4-5 de nosotros activos y debemos sopesar muy bien el uso de nosotros como recurso so pena que el proyecto se muera antes del inicio... en todo es solo mi opinion.

Lo q si tu ultima frase me deja preocupado, si defines un modelo debes plasmarlo tal cual en la etapa de codificacion, cualquier "cambio" debe ser motivado por alguna razon y aprobado por todos, y luego modificarse el modelo. Pero para eso esta la etapa de diseño para "ver" esos cambios y hacerlos sobre papel y no sobre codigo ya hecho q es mucho mas costoso...

Saludos / Best regards

Mario Lacunza
Email:: mlac...@gmail.com
Personal Website:: http://www.lacunza.biz/
OpenOffice.org Perú:: http://openoffice-peru.com/
Hosting:: http://mlv-host.com/
Mascotas Perdidas:: http://mascotas-perdidas.com/
Google Talk / Y! messenger / Skype: mlacunzav
MSN: mlac...@hotmail.com

El 02/05/13 11:22, Telefonica escribió:

Mario no solo codificando, pero también codificando se avanza.

 

El codificar algo, es para ir viendo muchas cosas, creación de interface normalizado con el usuario, soporte de mensajes multiidiomas, control de formularios, etc.., incluso el modelo q sigamos no tiene pq estar tal cual en la aplicación.

 

Saludos.

 

De: Mario Lacunza [mailto:mlac...@gmail.com]
Enviado el: jueves, 02 de mayo de 2013 16:29
Para: watc...@telefonica.net
Asunto: Re: Modelo piloto

 

por lo mismo me parece perdida tiempo hacer un modelo de algo q aun no se define y como interactua con lo demas :)  no solo codificando un proyecto se avanza :)

Saludos / Best regards

Mario Lacunza

Email:: mlac...@gmail.com

Personal Website:: http://www.lacunza.biz/

OpenOffice.org Perú:: http://openoffice-peru.com/

Hosting:: http://mlv-host.com/

Mascotas Perdidas:: http://mascotas-perdidas.com/

Google Talk / Y! messenger / Skype: mlacunzav

MSN: mlac...@hotmail.com

El 02/05/13 02:28, Manuel Calero escribió:

Mario,

 

Encantado de tenerte en este proyecto.

 

Por otro lado quería comentarte q si preparamos un modelo muy pequeño (p.e. países imagina q la aplicación se basa solo en esa tabla)  podemos ir preparando muchas cosas sobre este mini modelo, y después ir extendiendo el modelo.

 

Como tu bien dices el modelo se tendrá q modificar bastante.

 

No se encontraron virus en este mensaje.
Comprobado por AVG - www.avg.com
Versión: 2013.0.2904 / Base de datos de virus: 3162/6282 - Fecha de publicación: 04/29/13

[Axel Díaz]

Propongo la utilización de la aplicación Dia para hacer un diagrama de la base de datos. A partir de allí se podría empezar a tener al menos una entidad-relación moldeable antes de ponerse a 'echar código' a lo bruto. ¿Qué opinan?

Axel Díaz
San Juan de los Morros - Edo. Guárico
http://about.me/axelio
Linux User #531976

Usuario Canaima #1057

Huella de clave = D580 D9A2 41B0 412A E9A5  D778 DB05 8F60 BED7 96FB

[Javier Ramirez]

Opino hacer el hangout y verificar todo por ahi y ponerlo como documentación

La victoria la ganó un solo hombre... Jesús

[Mario Lacunza]

Dia te sirve tanto para los modelos UML como para los ER de la base de datos.

Sin embargo y dependiendo de la base de datos a usar (Mysql o postgresql) se podria usar mysql workbench o powerarchitect para PG ya q despues de crear los modelos en forma grafica tambien crean el codigo y las tablas si son conectados a la BD.

Alguien mas las uso?

Saludos / Best regards

Mario Lacunza
Email:: mlac...@gmail.com
Personal Website:: http://www.lacunza.biz/
OpenOffice.org Perú:: http://openoffice-peru.com/
Hosting:: http://mlv-host.com/
Mascotas Perdidas:: http://mascotas-perdidas.com/
Google Talk / Y! messenger / Skype: mlacunzav
MSN: mlac...@hotmail.com

El 03/05/13 06:46, Axel Díaz escribió:

[Marcelo]

Que opinan de usar https://www.lucidchart.com ?

[Mario Lacunza]

No entiendo como haría la bd sin tener el modelado previo??

Enviado desde mi Nexus 4

El 03/05/2013 10:56, "Axel Díaz" <diaz....@gmail.com> escribió:

Pero tendrías que hacer la BD para luego graficar, y la idea es graficar antes de hacer la BD no? Evitar el uso de códigos así sea para crear la primera base de datos.

BTW, opino que PostgreSQL es mucho más potente para un proyecto como este. +1 con PostgresSQL

[Yordis Prieto]

Mi opinion es que deberian de enfocarse en la arquitectura del ERP, el cómo, al final el ERP son pequeños modulos compuesto por vistas con su logica de negocio y sus tablas para guardar la informacion. 

Definiendo una buena arquitectura que te permita el trabajo facil sin importar que tan dura es la logica de negocio o las tablas que pones en juego, si no se establece un flujo del ERP no se puede empesar a codiar o generar DB, al final solo vas a tener una relacion de tablas solo eso, en cambio defiendo el flujo del ERP el trabajo se limita  a resolver el requerimiento funcional.

Por experiencia propia en un ERP que estaba haciendo, nos enfocamos en relaciones de tablas, tablas, tablas. A mitad del proyecto tuvimos que para porque nos dimos cuenta que definiendo una arquitectura se podian ahorar horas haciendo exaptamente lo mismo, y definimos una arquitectura que te permitia hacer las cosas una sola vez sin importar que tan complicado era