Modulos del Sistema

[Mario Lacunza]

Siguiendo con lo definido hasta el momento, tenemos los siguientes módulos:

1. Administración,
2. Empresas,
3. Ventas,
4. Compras,
5. Almacén,
6. Tesorería,
7. Recursos humanos,
8. Producción,
9. Contabilidad
10. Reportes

Para mi faltan Clientes, Proveedores.

Tesoreria: debe contar con Caja (TPV) yBancos como submodulos?

El modulo de Administración es donde se guardan los parametros del sistema? Seguridad/Usuarios tambien o es modulo aparte?

Modulo de Auditoria del sistema? es decir quien hizo que y cuando?

RRHH: debe contar con un submodulo de Planillas o es modulo aparte?

No veo modulo de cuentas pendientes: Ctas por pagar y cobrar o va dentro de tesoreria?

No hay modulo de Ayuda/Manual

Hasta el momento todo lo q se me ocurre.. por favor espero sus comentarios y aportaciones. Terminando de definir los modulos podemos empezar creo yo con los requerimientos de c/u al detalle.

[Mario Lacunza]

aja se me escapo proponer un modulo tipo Nucleo/Motor o Cerebro que sea como el coordinador general de todo el sistema.

[Javier Ramirez]

Yo pondria clientes y proveedores

Los bancos para mi lo tendria como submodulos ya que pueden haber cambios de una localizacion a otra

Seguridad y usuarios yo lo pondria en lugares diferentes es mas facil al asignar un acceso a un usuario

El modulo de auditoria no estaria mal ponerlo.

Las cuentas yo lo pondria dentro de tesoreria.

Luego clientes y temas asi lo pondria relacionado uno o varias direcciones y asignado a unos o varias personas de contacto.

Las planillas/nominas (como le decimos aqui) cambian en cada localizacion (algunas no) pero ya que hay variaciones tiene que estar en un modulo aparte (aqui tienen algo que estan sujeto a IVA IGIC y un par de papeleos mas)

--
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.
 
 

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

[Manuel A. Estevez Fernandez]

La parte del Nucleo / motor en lo personal lo incluría en una sección de configuración. Además de tener contemplado una zona de utilerias para colocar todo lo que tal vez no pertenezca a algún área. Como la parte de auditoria de accesos. 

Saludos.

by:

ISC. Manuel Alejandro Estévez Fernández

[Mario Lacunza]

Ok entonces va quedando asi:

1. Nucleo/Configuración/Administración,
2. Empresas,
3. Clientes
4. Proveedores
   
5. Ventas,
6. Compras,
7. Almacén,
8. Tesorería: Bancos, Caja, Ctas x Cobrar, Ctas x Pagar
   
9. Recursos humanos: Planillas/Nominas, RRHH
   
10. Auditoría
    
11. Producción,
12. Contabilidad
13. Reportes
14. Seguridad/Usuarios
    

Seguridad y usuarios siempre van juntos, xq todo sistema a parte del login debe tener un sistema de usuarios y permisos asignados por grupos. Asi al grupo se le dan los permisos especificos y los users se agregan a estos, heredandolos.

Clientes/Proveedores son dos entidades distintas, como se guarden en la BD es otra cosa y se vera en su momento, tengan esto en mente al hacer sus comentarios.

Quisiera poner en consideración un modulo de Asistencia del personal el cual deberia de ir dentro de Recursos Humanos, q piensan?

[Javier Ramirez]

Si pienso que asistencia deberia ir dentro de recursos humanos

--
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.
 
 

[Mario Lacunza]

1. Nucleo/Configuración/Administración,
2. Empresas,
3. Clientes
4. Proveedores
   
5. Ventas,
6. Compras,
7. Almacén,
8. Tesorería: Bancos, Caja, Ctas x Cobrar, Ctas x Pagar
   

1. Recursos humanos: Planillas/Nominas, RRHH, Asistencia
   

1. Auditoría
   
2. Producción,
3. Contabilidad
4. Reportes
5. Seguridad/Usuarios

Agregado....

[Manuel A. Estevez Fernandez]

En cuando a los catalogos necesarios.. ¿irán separados por el módulo principal al que pertenecen o será un apartado con todos?

by:

ISC. Manuel Alejandro Estévez Fernández

--

[Mario Lacunza]

Como es eso de catalogos? podrias explicarme como funcionan..

[Manuel A. Estevez Fernandez]

Los catalogos serían las entidades base, digamos proveedores, clientes, usuarios, perfiles de usuario, mercancias, almacenes, vehiculos, precios, ofertas.

No se como los conozcas.

by:

ISC. Manuel Alejandro Estévez Fernández

[Mario Lacunza]

Te sigo sin intender, eso mismo veo en la relacion de modulos ya planteada... o q tareas hacen los catalagos segun lo q planteas? son listados? son los mantenimientos de cada modulo?

[Javier Ramirez]

Lo que entiendo es la relacion producto precio proveedor ...

[Manuel A. Estevez Fernandez]

son los modulos de mantenimiento.  

by:

ISC. Manuel Alejandro Estévez Fernández

[Mario Lacunza]

Ahora si!! :D

Matenimientos:

bueno hay dos formas de afrontarlo:

1. Tener un modulo especial/centralizado para todos los otros modulos
   
2. Que cada modulo tenga su propia opcion de ABM (Altas Bajas Modificacion) 

Yo me inclino de hecho por la segunda asi los Modulos mantienen su independencia y encapsulacion, ya q considero q es parte inherente al mismo Q opinan?

[Manuel A. Estevez Fernandez]

Estoy completamente de acuerdo, que sean independientes, ahora propongo que no haya bajas como tales (delete) sino cambios de estado activo/inactivo (borrado lógico).

by:

ISC. Manuel Alejandro Estévez Fernández

[Mario Lacunza]

Para unificar terminos:

Catalagos == Mantenimientos == Tablas Maestras

Como me indica Manuel Calero (no te olvides de responder a la lista)

[Javier Ramirez]

Aa ok es que para nosotros catalogo es eso...

Estoy de acuerdo con Manuel A. Estevez Fernandez

[Mario Lacunza]

De acuerdo con lo del borrado logico, indispensable para el modulo de auditoria y algunos historicos.

[Manuel Calero]

Ahora estoy respondiendo a la lista?

[Mario Lacunza]

Afirmativo!! :)

[Manuel Calero]

Gracias Mario, q haríamos sin ti ;)

[Javier Ramirez]

jajajaja correcto, totalmente de acuerdo con el borrado logico, pero ¿Cuando se hara el cambio real? ¿cuando cierre?

[Manuel A. Estevez Fernandez]

¿Te refieres a como se aplica? Se hace con un campo de estado por ejemplo:

1 - Activo

2 - Inactivo

3 - Borrado

solo por mencionar algunos.

by:

ISC. Manuel Alejandro Estévez Fernández

[Mario Lacunza]

Resumen hasta el momento, el orden es solo convención no representa ninguna prioridad.

Modulos Sistema:

Auditoría

Producción,
Contabilidad
Reportes
Seguridad/Usuarios/Login

Estoy agregando el modulo de Login en el Nro 14 como submodulo

Se usara borrado Logico y no directo en la BD para esto deberá implementarse en todas las tablas de la BD un campo fijo tipo flag para este fin definido como Integer de un solo digito con opciones:

0= Inactivo

1= Activo

2= Borrado

[Jordi Marco]

Hola;

Si realizamos un borrado lógico; podriamos implemetar auditoria en las tablas;

Propongo poner el usuario que ha realizado la operación;

Añadiendo un campo tipo varchar.

Saludos

--

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)

[Manuel Calero]

Jordi,

Creo q lo mejor es crearlo mediante Triggers en la propia base de datos, asi nos evitamos mucho código.

[Jordi Marco]

Estoy de acuerdo hacerlo por triggers; pero las tablas tendrian que tener el valor;

Saludos

[Manuel Calero]

Jordi,

Me he perdio.

[Jordi Marco]

Poner un campo en la tabla, con valor del usuario.

[Manuel Calero]

Jordi

No se para q se para q sirve eso, yo todo el control de auditorias lo llevo en tablas externas a los datos.

[Jordi Marco]

Ok;

Si se implementa la auditoría de la manera que comentas, me parece correcto.

Lo importante creo yo es que implementemos una auditoría. Porque creo le dariamos un valor añadido grande al producto final.

Saludos

[Manuel Calero]

Las auditorias son imprescindibles para cualquier producto medianamente serio.

[Javier Ramirez]

sobre todo aqui que se hacen cada 2 x 3

[Mario Lacunza]

Aja veo q están despiertos...Jaja

Se puede hacer de las dos formas q proponen...

1. En cada tabla se agregan los campos necesarios para iduser (un integer ya q es una foreign key) y un date para fecha de modificación.
2. Tablas externas

y dado q son usuarios del sistema y no de la base de datos se tiene q hacer x código salvo q alguien programe la PostgreSQL para esto, en todo caso se verá en su momento.

Terminemos de definir módulos y luego nos metemos a discutir detalles así avanzamos más rápido :)
Algún módulo adicional q se requiera? Sino nos ponemos a ver ya los pormenores del sistema.

Enviado desde mi Samsung Galaxy S4

[Mario Lacunza]

Puedes explicarla? Soy nuevo con django

Responder a la lista...

Enviado desde mi Samsung Galaxy S4

El 28/05/2013 07:47, "Axel Díaz" <diaz....@gmail.com> escribió:

¿En cada tabla agregar un id_user y un date? Disculpen mi intromisión pero, ¿para eso no están los históricos propios de Django?

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

[Axel Díaz]

Django crea por defecto registros en los modelos automáticamente. Cuando uno hace una vista, puedes hacer que al momento de modificar o agregar algo nuevo genere un nuevo registro en los históricos de ese/esos modelo/s involucrado/s. Acá un ejemplo: http://imagebin.org/259320 Esto sería el histórico de un estudiante que aprobaron su preinscripción y validaron sus documentos... La validación es un simple booleano de válido o no. Y la aprobación del preinscrito es un conjunto de operaciones para que el estudiante aspirante, tenga una cuenta en el sistema, esté listo para ajustes de horarios, entre otros pasos para que el preinscrito sea un estudiante inscrito regular. 

A lo que me refiero, Django provee ya herramientas para históricos y así ahorrarnos esto de crear una tabla para Usuario, Fecha, etc sólo para guardar los movimientos de un registro...

El 28 de mayo de 2013 08:46, Axel Díaz <diaz....@gmail.com> escribió:

Django crea por defecto registros en los modelos automáticamente. Cuando uno hace una vista, puedes hacer que al momento de modificar o agregar algo nuevo genere un nuevo registro en los históricos de ese/esos modelo/s involucrado/s. Acá un ejemplo: http://imagebin.org/259320 Esto sería el histórico de un estudiante que aprobaron su preinscripción y validaron sus documentos... La validación es un simple booleano de válido o no. Y la aprobación del preinscrito es un conjunto de operaciones para que el estudiante aspirante, tenga una cuenta en el sistema, esté listo para ajustes de horarios, entre otros pasos para que el preinscrito sea un estudiante inscrito regular. 

A lo que me refiero, Django provee ya herramientas para históricos y así ahorrarnos esto de crear una tabla para Usuario, Fecha, etc sólo para guardar los movimientos de un registro...

[Mario Lacunza]

Excelente! Una cosa menos q programar :)

Enviado desde mi Samsung Galaxy S4

[Javier Ramirez]

Jaja cierto

Desde el móvil disculpe las molestias

[Marcelo Leiva Sandoval]

Genial :)

Enviado desde mi iPhone

[Mario Lacunza]

El nuevo update:

Modulos Sistema:

1.     Nucleo/Configuración/Administración,
2.     Empresas,
3.     Clientes
4.     Proveedores
5.     Ventas,
6.     Compras,
7.     Almacén,
8.     Tesorería: Bancos, Caja, Ctas x Cobrar, Ctas x Pagar
9.     Recursos humanos: Planillas/Nominas, RRHH, Asistencia

1.     Producción,
2.     Contabilidad
3.     Reportes
4.     Seguridad/Usuarios/Login

Estoy agregando el modulo de Login en el Nro 14 como submodulo

Se usara borrado Logico y no directo en la BD para esto deberá implementarse en todas las tablas de la BD un campo fijo tipo flag para este fin definido como Integer de un solo digito con opciones:

0= Inactivo

1= Activo

2= Borrado

Se habilitara la auditoria por default que viene con Django.