jun 28

Analisis de una aplicación completa

Posted in analisis, aplicaciones

En esta ocasión y para variar voy a mostrar el esquema de una pequeña y sencilla, pero completa aplicación de gestión.

Y vamos a ver algunos conceptos importantes que debemos tener en cuenta al diseñar nuestra base de datos.

Para este ejemplo he decidido que necesitamos una gestión que nos permita controlar varias empresas al tiempo, que sea multi-ejercicio y multi-almacén.

Nuestra gestión, tambien debe ser capaz de tramitar albaranes de compra, albaranes de venta, movimientos de almacen y por supuesto, la posibilidad de facturar los albaranes y contabilizar las facturas generadas.

Como ya se explicó anteriormente en el articulo sobre la abstracción, debemos analizar cada punto del esquema y decidir si nos conviene abstraer el esquema o mantener la sencillez en el desarrollo.

El esquema final que ha resultado de todo este planteamiento es el siguiente:

Esquema de gestión

No es quizá el esquema mas abstracto, ya que podriamos haber utilizado una misma tabla para todos los movimientos de almacén, pero he decidido que para según que tipo de negocio, no es necesaria dicha abstracción y he preferido prescindir de ella en favor de un mantenimiento mas sencillo por parte del desarrollador que se inicia.

No obstante, si he usado una única tabla de entidades, que seria utilizada para clientes y proveedores, con el fin de evitar duplicidad en los datos introducidos por el usuario.

Analicemos los puntos mas importantes de la aplicación y veamos cuales son sus ventajas y sus inconvenientes:

¿Utilizar una OpenApp o desarrollar una nueva?

Esta pregunta, debemos responderla antes de comenzar, ya que de no ser asi, podria ser necesario repetir parte de la tarea de analisis y la perdida de tiempo que conlleva. Usar una OpenApp está muy bien, ahorra trabajo, y podria estar preparada en poco tiempo con algunas modificaciones y correcciones, pero ¿se ajusta el esquema a lo que necesito?, o lo que es mas importante, ¿que me va a llevar mas tiempo, realizar mi propio esquema o entender el esquema de la OpenApp?

¿Todo en un proyecto o usamos varios proyectos?

Lo primero que deberiamos decidir, ya que al menos de momento, no es posible separar las tablas de un proyecto en 2 proyectos diferentes, es si vamos a mantener todas las tablas dentro del mismo proyecto o no. Si queremos aprovechar la potencia de la herencia para reutilizar el esquema para otras posibles aplicaciones que pudieramos tener pendientes, deberiamos separar las tablas en varios esquemas, pero ¿cuantos?, ¿que tablas en cada proyecto?, ¿que proyectos heredan y cuales son heredados?. También podemos optar por mantener unido todo el conjunto y hacer mas sencillo el desarrollo, pero en este caso, el futuro de la aplicación estará muy limitado por esta decisión.

¿Que tipos de tablas y que relaciones debe haber entre las tablas?

Ya decidida la parte anterior, ahora nos toca profundizar un poco mas y saber de que tipo va a ser cada una de las tablas usadas en el proyecto, maestra, submaestra, historica, y analizar una a una con sus ventajas e inconvenientes.

¿Entidades multi-empresa o no?

En este punto deberiamos decidir si la tabla de entidades deberia ser historica de empresas o no, si tenemos en cuenta que al ser Multiempresa, un cliente/proveedor deberia ser creado tantas veces como empresas tengamos y dicha entidad realice operaciones con la empresa. Si la tabla Entidades no es multiempresa, al crear un cliente/proveedor estara disponible para todas las empresas desde ese instante.

Compras, ventas y almacén, ¿juntas o separadas en tablas diferentes?

Como he indicado anteriormente, si utilizamos las mismas tablas para movimientos de almacén, el usuario final no deberia notar absolutamente nada, pero para el desarrollador puede ser mas complicado mantener esa aplicación, y puede ocasionar errores en futuras actualizaciones de la aplicación si no se tiene mucho cuidado al realizar los cambios.

Facturas de compra y venta, ¿ que relación deben tener con contabilidad?

Las facturas deben ser maestras o historicas de los asientos y/o apuntes contables, o quizá no deberian tener ninguna relación. Si relacionamos las facturas con los asientos, esto nos permitiria mantener la integridad entre gestión y contabilidad, pero si deseamos que nuestra contabilidad pueda ser usada por multiples aplicaciones de gestión con estructuras diferentes, deberiamos pensar en separar la contabilidad, y desarrollarla completamente por separado.

Los vencimientos, ¿en contabilidad o en gestión?

Si esta pregunta se la hacemos a un contable, su respuesta sería clara y rotunda, ¡en contabilidad!, pero si tenemos una gestión de ventas y procesos de facturación, no tiene mucho sentido que tengamos que introducir los vencimientos manualmente, ¿o quizá si?

¿Hasta donde queremos llegar?

Otra pregunta muy importante que debemos tener muy clara, es ¿hasta donde queremos llegar en este proyecto?, ¿que necesidades tenemos?, ¿el esquema planteado aqui es suficiente o necesitas más?, y si es asi, ¿cuanto más?

Plantear una aplicación, necesita muchas preguntas, y sobre todo, tener claras las respuestas a esas preguntas, y solo asi conseguiremos que en el futuro no tengamos sorpresas desagradables por problemas no previstos.

Y no voy a ser yo quién os diga lo que debeis hacer en cada momento, este articulo, pretende crear un debate y que cada uno pregunte o responda a lo que pueda ser su diseño más apropiado.

Para nuestra solución, ya hemos tomado todas las decisiones importantes y estamos avanzando en el desarrollo, pero cada aplicación es muy personal, y debeis encontrar las respuestas a vuestras necesidades.

PDF Download    Enviar artculo en formato PDF   
comments: 6 »